array and pointer declarations, faq 6.4 
Author Message
 array and pointer declarations, faq 6.4

So, I read the FAQ, and I thought that these function declarations
were identical.

foo(char *bar)
foo(char bar[])

I've been using the latter with the AIX C compiler and several
68K cross compilers with no problem.  

Now I get to Borland C++ 4.52, which accepts:

void ws_load_data(u_char *command, const u_char *data, u_char byte_count)
{
    int byte;
    for (byte=0 ; byte<byte_count ; byte++) {
        *command++ = *data++;
    }

Quote:
}

but rejects:

void ws_load_data(u_char command[], const u_char data[], u_char byte_count)
{
    int byte;
    for (byte=0 ; byte<byte_count ; byte++) {
        *command++ = *data++;
    }

Quote:
}

with the error:

"Cannot modify a const object in function ws_load_data."

Is this caused by:

1 - A change in C++
2 - Something to do with the const modifier
3 - A Borland quirk
4 - I'm reading the FAQ incorrectly
5 - Something else I'm missing
6 - All of the above
--



Sun, 04 Jul 1999 03:00:00 GMT  
 array and pointer declarations, faq 6.4

HPUX C doesn't treat they identically when -O is turned on.  Arrays
declared in the called function with [] notation are treated as
non-aliased and are optimized like fortran.
Tim



Thu, 08 Jul 1999 03:00:00 GMT  
 array and pointer declarations, faq 6.4


 > >[description of odd behavior deleted]
 > >
 > >Is this caused by:
 > >
 > >[other possibilities deleted]
 >
 > >3 - A Borland quirk
 >
 > You've misspelt "bug", IMHO.

Which is, in turn, a misspelling of "defect".

In my experience, people take "defects" quite a bit
more seriously than they do "bugs".  For some reason,
a "bug" seems to be more tolerable than a "defect",
even when they're referring to the same thing.



Thu, 08 Jul 1999 03:00:00 GMT  
 array and pointer declarations, faq 6.4

<snip: asks about>

Quote:
> void ws_load_data(u_char *command, const u_char *data, u_char byte_count)
<snip: vs>
> void ws_load_data(u_char command[], const u_char data[], u_char byte_count)
> {
>     int byte;
>     for (byte=0 ; byte<byte_count ; byte++) {
>    *command++ = *data++;
>     }
> }

> with the error:

> "Cannot modify a const object in function ws_load_data."

<snip>

Assuming data++ is the only thing causing trouble here (it would have
been nicer if you had chosen an example where the separate
modifications data++, command++ and *command = were all in separate
statements and lines so that we could figure out which of them the
compiler is complaining about.), this is very confusing, and seems
more like a *parser* error. const u_char data[] under *no condition*
could have made data into a const, it qualifies the element type of
data, not the array (or pointer) data itself. (unless some clever bozo
is trying to take care of the const T (*) [] <-- T (*) [] assignment
compatibility problem in some bizarre way.)

Or does the compiler complain about both command++ and data++, in
which case the interpretation would be that [] is being rewritten
incorrectly as *const instead of *: which I could believe some C++
committee at some stage will mandate/has mandated.

Quote:

> HPUX C doesn't treat they identically when -O is turned on.  Arrays
> declared in the called function with [] notation are treated as
> non-aliased and are optimized like FORTRAN.

This is just implementing the `future language directions'. Though
implementing it is non-conforming at the moment, the standard clearly
intends it to be conforming later.

I do not see, however, what *that* has to do with the case at
hand. The future language direction section still leaves the rewrite
rule intact: it simply talks about nonaliasing.

Cheers
Tanmoy
--

Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]



Fri, 09 Jul 1999 03:00:00 GMT  
 array and pointer declarations, faq 6.4

Quote:

>HPUX C doesn't treat they identically when -O is turned on.  Arrays
>declared in the called function with [] notation are treated as
>non-aliased and are optimized like FORTRAN.

Which simply says that if you use the HPUX compiler with the -O option
then it isn't a C compiler.

--
-----------------------------------------


-----------------------------------------



Tue, 13 Jul 1999 03:00:00 GMT  
 array and pointer declarations, faq 6.4

Quote:



>  > >[description of odd behavior deleted]

>  > >Is this caused by:

>  > >[other possibilities deleted]

>  > >3 - A Borland quirk

>  > You've misspelt "bug", IMHO.

> Which is, in turn, a misspelling of "defect".

> In my experience, people take "defects" quite a bit
> more seriously than they do "bugs".  For some reason,
> a "bug" seems to be more tolerable than a "defect",
> even when they're referring to the same thing.

Actually, this particular "defect" is almost certainly an "error" or a
"mistake".  I can't believe they did it intentionally.

It's interesting to note that 1 bug in 1000 lines of code doesn't sound
too bad, but if anyone tells you that you make a mistake every 1000
lines of code, you sound stupid.  Similarly, everyone expects bugs, and
so they don't worry about preventing them.  On the other hand, no one
likes to be told they made a mistake, and so they try and avoid them.

--

GABI Software, Sarl., 22 rue Jacques-Lemercier, 78000 Versailles, France
                          -- Conseils en informatique industrielle --



Tue, 13 Jul 1999 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Irix 6.4 64/n32 sprintf problem

2. Transform c program from BSD 4.3 system to SuSE linux 6.4

3. __LONG_MAX__ in gcc 2.8.1 under SGI IRIX 6.4

4. Notification of volume change in ActiveMovie 6.4

5. array declaration vs. char pointer

6. Declaration of 2D array with pointer ???

7. Arrays of function pointers (nomination for FAQ)

8. Array of pointers, pointer to array...

9. Dereferencing f-pointers, arrays of f-pointers, pointers to f-pointers

10. array pointer/pointer array

11. arrays pointers array of pointers

12. Pointers to pointers to functions declaration

 

 
Powered by phpBB® Forum Software