C Pointer problem

S

Simon Biber

Richard said:
Let me get this straight - you didn't actually /write/ the core code for
lcc-win32, did you? Because if you did, I think it's time for me to start
warning people not to use it.

Well, of course, the original LCC compiler was not written by Jacob. It
was written by Chris Fraser and David Hanson. LCC was written in a very
simple and well-documented way, and they published a book describing it
in detail.

Jacob has been hacking on Lcc-Win32 for a long time now - since 1995.
I'm sure he has a very good understanding of the compiler by now.

Simon.
 
J

Jordan Abel

This is not true. Please see
http://open-std.org/JTC1/SC22/WG14/www/docs/dr_317.htm
for an official answer stating so.

That interpretation does not follow from that wording. If that was
_really_ what they meant, they should have worded it differently. It
says "no parameters". The fact that there is any distinction at all
between "An empty list in a function declarator that is part of
a function definition" and one in one that is not, proves my point.

The standard is clear. If "the committee" is free to change the meaning
of the standard even when no ambiguity existed in the first place, then
the standard has no meaning at all.
 
J

Jordan Abel

Jordan Abel a écrit :
Interesting. Maybe you know where in the standard that is
stated?

The sentence that the committee repudiates in the DR that someone
elsewhere in this thread linked.
 
G

Guest

Jordan said:
That interpretation does not follow from that wording. If that was
_really_ what they meant, they should have worded it differently. It
says "no parameters". The fact that there is any distinction at all
between "An empty list in a function declarator that is part of
a function definition" and one in one that is not, proves my point.

The behaviour is defined in some cases if a function declared as int
f() is called with arguments. The behaviour is never defined if a
function defined as int f() is called with parameters. There seems to
be a good reason for the distinction to me.

If you say a diagnostic is required for foo(42), could you please tell
me which constraint you believe is violated?
 
J

jacob navia

Richard Heathfield a écrit :
So what? You should still know about the circumstances in which messages can
be produced, and you should still know that "diagnostic message" is not the
same as "error". That was all the information you needed to have at your
disposal to avoid asking the question "Why is that an eror?"

I have to confess that I was unsure at that warning, not seeing the
specific options to gcc, so I commited the sin of asking a question
something that Mr Heathfield doesn't forgive me.

Let me get this straight - you didn't actually /write/ the core code for
lcc-win32, did you? Because if you did, I think it's time for me to start
warning people not to use it.

Well, maybe is time to re-read your gcc manual too.
The -W option that you used is deprecated. Use -Wextra instead.

Did you know that?

Apparently no.

Ahhh GOTCHA!!!!

Isn't that silly really? Asking you a question is a crime? :)

Peace

jacob
 
R

Richard Heathfield

jacob navia said:
Well, maybe is time to re-read your gcc manual too.
The -W option that you used is deprecated. Use -Wextra instead.

So what?

(a) I don't agree that everything gcc deprecates is necessarily worthy of
deprecation.
(b) My version of gcc doesn't support -Wextra.
(c) This is an implementation issue, not a language issue.
Did you know that?

If the question is "did I know that an implementation version that I don't
use introduced a new flag that I don't have", then the answer is simple:
questions about specific implementations should be asked in newsgroups
devoted to those implementations.

We've explained this to you before.
Ahhh GOTCHA!!!!

Oh, grow up.
 
D

Dave Thompson

False. The standard makes a very clear distinction between empty
brackets in a declaration not part of a definition, and empty brackets
that _are_ in part of a definition. And the latter is EXACTLY equivalent
to (void).

Where?

6.7.5.3p14 says "An empty
list in a function declarator that is part of a definition of that
function specifies that the
function has no parameters."

It does NOT say that it is or functions as a prototype.

6.9.1p7 says "If the declarator includes a parameter type list,"
meaning new=prototype form it "also serves as a
function prototype for later calls to the same function in the same
translation unit." It then proceeds to the other case "If the
declarator includes an identifier list," meaning old form which
includes empty parentheses, where it says no such thing.

_C++_ effectively has only prototype form and actually says the
reverse: 8.3.5[dcl.fct]p2 "The parameter list (void) is equivalent
to the empty parameter list." (for both declarations and definitions).

This is one of the several reasons people here keep saying like a
mantra that C++ is NOT a superset of C.

It is fairly easy for a compiler to produce a diagnostic in this case,
as good QoI. But it is not required by the C standard.

- David.Thompson1 at worldnet.att.net
 
P

pete


What?

N869
Index

( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
[ ] (brackets punctuator), 6.7.5.2, 6.7.8
{ } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2
 
D

Dave Thompson


What?

N869
Index

( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
[ ] (brackets punctuator), 6.7.5.2, 6.7.8
{ } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2

Are you being dense? He obviously meant brackets in the en_GB (or UK?)
meaning, what en_US (and the standard) calls parentheses.

- David.Thompson1 at worldnet.att.net
 
P

pete

Dave said:
Dave said:
On 1 Jun 2006 01:26:09 GMT,

2006-05-31
Peter Nilsson wrote:
int foo() { }
The standard makes a very clear distinction between empty
brackets in a declaration not part of a definition,
and empty brackets that _are_ in part of a definition.

What?

N869
Index

( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
[ ] (brackets punctuator), 6.7.5.2, 6.7.8
{ } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2

Are you being dense?

I am dense.
He obviously meant brackets in the en_GB (or UK?)
meaning, what en_US (and the standard) calls parentheses.

The example shown had empty parentheses and empty braces
and he was saying something that you suggest was false
about empty brackets.
So where's my clue as to what he's talking about?
 
A

Andrew Poelstra

Dave said:
2006-05-31 <[email protected]>,
Peter Nilsson wrote:
int foo() { }
The standard makes a very clear distinction between empty
brackets in a declaration not part of a definition,
and empty brackets that _are_ in part of a definition.

What?

N869
Index

( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
[ ] (brackets punctuator), 6.7.5.2, 6.7.8
{ } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2

Are you being dense? He obviously meant brackets in the en_GB (or UK?)
meaning, what en_US (and the standard) calls parentheses.

I know a lot of people who refer to []{}<>() as brackets (and some who
call quotes brackets), and it's much easier to just define everything
one way and act dense when others define them differently.

Sure, it was obvious that he didn't mean [] by "bracket". But what /did/
he mean? There was an empty () and an empty {} in the code.


Just my thoughts on why people don't like to talk to me. :)
 
P

pete

pete said:
Dave said:
Dave Thompson wrote:

On 1 Jun 2006 01:26:09 GMT,

2006-05-31
Peter Nilsson wrote:

int foo() { }

The standard makes a very clear distinction between empty
brackets in a declaration not part of a definition,
and empty brackets that _are_ in part of a definition.

Where?

What?

N869
Index

( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
[ ] (brackets punctuator), 6.7.5.2, 6.7.8
{ } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2

Are you being dense?

I am dense.

My point actually is that I always advocate using
C standard terminology when discussing the C standard
on this newsgroup.
 
M

Mark McIntyre

The example shown had empty parentheses and empty braces
and he was saying something that you suggest was false
about empty brackets.

It was, obviously, contained within the brackets. -)
So where's my clue as to what he's talking about?

Two nations divided by a common language indeed.

For the record, brackets come in three flavours, square, wiggly and
plain.

gd&r
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
B

Bill Pursell

Mark said:
For the record, brackets come in three flavours, square, wiggly and
plain.

I've heard them called "curly, "squiggly", and "squirrely", but
I don't believe i've ever seen them called "wiggly" before. (I think I
usually call them "curly brackets" or sometimes "braces").

-Bill
 
C

Chris Dollin

Mark said:
It was, obviously, contained within the brackets. -)


Two nations divided by a common language indeed.

For the record, brackets come in three flavours, square, wiggly and
plain.

You forgot <pointy>.
 
S

Simon Biber

Mark said:
For the record, brackets come in three flavours, square, wiggly and
plain.

Four flavours:

(normal brackets)
[square brackets]
{curly brackets}
<angle brackets>

Even a simple C program uses all four flavours:

#include <stdio.h> // angle brackets
int main(int argc, char **argv) // normal brackets
{
printf("program name: %s\n",
argv[0] ? argv[0] // square brackets
: "none");
return 0;
} // curly brackets

Someone tell me, does one learn PODMAS instead of BODMAS in the USA?
(Brackets, Orders, Division/Multiplication, Addition/Subtraction)
 
F

Frederick Gotham

Simon Biber posted:

Someone tell me, does one learn PODMAS instead of BODMAS in the USA?


I actually learned BOMDAS at school, rather than "BODMAS".

Brackets
Off
Multiply
Divide
Add
Substract


Looks like we'd interpret the following differently:


5 * 4 / 2 * 5




If we multiply first, we get 2.
If we divide first, we get 50.


But of course C gives them equal precedence and works left to right, so
we'd get 50.
 
S

Simon Biber

Frederick said:
Simon Biber posted:




I actually learned BOMDAS at school, rather than "BODMAS".

Brackets
Off
Multiply
Divide
Add
Substract

It makes no difference. Either way you have to remember that Multiply
and Divide have equal precedence and are evaluated left to right.
Similarly, Add and Subtract have equal precedence and are evaluated left
to right.
Looks like we'd interpret the following differently:
5 * 4 / 2 * 5
If we multiply first, we get 2.
If we divide first, we get 50.

The correct answer is 50, however it's just by chance that this is also
achieved by dividing first.

In general you do not achieve the correct answer by multiplying first or
by dividing first, but rather by working left to right.
 
F

Frederick Gotham

Simon Biber posted:

In general you do not achieve the correct answer by multiplying first or
by dividing first, but rather by working left to right.


Yes I am well aware of how C operator precedence works -- I was referring
to the way human beings do math.

On the European side of the Atlantic, we learn BOMDAS rather than BODMAS,
and this would lead us to interpret the following line differently:

4 * 12 / 3 * 8


C compiler interpretation: 128

American interpretation: 128

European interpretation: 2
 
M

Mark McIntyre

On the European side of the Atlantic, we learn BOMDAS rather than BODMAS,
and this would lead us to interpret the following line differently:

4 * 12 / 3 * 8


C compiler interpretation: 128

American interpretation: 128

European interpretation: 2

Euh. only if you put in some brackets. I can't otherwise see how four
times twelve thirds times eight can equal two.

But then, everything *is* bigger in the States. :)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,431
Messages
2,571,677
Members
48,796
Latest member
Greg L.

Latest Threads

Top