ANSI C Newbie Question

[Randy Howard]

Add in -W and what is the problem? I think the result catches most
outright violations.

I suspect he was talking about making assumptions about byte size,
buffer overflows, shifting errors, and host of other "corner cases"
in the language that gcc won't issue a warning for AFAIK.

 

[Keith Thompson]

When you invoke lcc-win32 with
lcc -ansic foo.c

*All* extensions are disabled.

This is
1) written in the documentation
2) It has an own button in the IDE
3) I have repeated it here at least once a month since at least
one year.

That's good to know. I actually didn't remember seeing you mention
this here, but I did manage to find at least one reference through
groups.google.com (Google makes it hard to search for "-ansic"), so
I'll take your word for it.

 

[CBFalconer]

(e-mail address removed) says...

I suspect he was talking about making assumptions about byte size,
buffer overflows, shifting errors, and host of other "corner cases"
in the language that gcc won't issue a warning for AFAIK.

Well, those problems are inherent to the language, and nothing much
could ever avoid them, apart from immersing Kernighan and Ritchie
in Pascal for about 3 years before they developed RATFOR.
Unfortunately Pascal wasn't ready in time for that, and if it had
been we wouldn't have a low level language now.

Just make sure all your errors are portable.

 

[infobahn]

Add in -W and what is the problem?

Let's see...

I think the result catches most
outright violations. It won't catch stupidities and faulty coding,
failure to check error returns, failure to ensure objects have the
capacity to hold the desired values, etc.

Aha! /There's/ the problem.

 

[Emmanuel Delahaye]

jacob navia wrote on 25/02/05 :

type example.c
int __declspec(dllexport ) a;
int main(void)
{
__try {
int a=0;
}
__except(0) {
int b=0;
}
}

main.c:1: parse error before "example" main.c: In function `main':
main.c:5: `__try' undeclared (first use in this function)
main.c:5: (Each undeclared identifier is reported only once
main.c:5: for each function it appears in.) main.c:5: parse error
before '{' token main.c: At top level:
main.c:8: parse error before numeric constant
main.c:8: warning: return type defaults to `int'
main.c:8: warning: function declaration isn't a prototype main.c: In
function `__except':
main.c:9: warning: unused variable `b' main.c: At top level:
main.c:11: parse error before '}' token

What's your point ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.

 

[Emmanuel Delahaye]

(supersedes <[email protected]>)

jacob navia wrote on 25/02/05 :

type example.c
int __declspec(dllexport ) a;
int main(void)
{
__try {
int a=0;
}
__except(0) {
int b=0;
}
}

main.c: In function `main':
main.c:4: `__try' undeclared (first use in this function)
main.c:4: (Each undeclared identifier is reported only once
main.c:4: for each function it appears in.)
main.c:4: parse error before '{' token main.c: At top level:
main.c:7: parse error before numeric constant
main.c:7: warning: return type defaults to `int'
main.c:7: warning: function declaration isn't a prototype
main.c: In function `__except':
main.c:8: warning: unused variable `b'
main.c: At top level:
main.c:10: parse error before '}' token

What's your point ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[jacob navia]

(supersedes <[email protected]>)

jacob navia wrote on 25/02/05 :



main.c: In function `main':
main.c:4: `__try' undeclared (first use in this function)
main.c:4: (Each undeclared identifier is reported only once
main.c:4: for each function it appears in.)
main.c:4: parse error before '{' token main.c: At top level:
main.c:7: parse error before numeric constant
main.c:7: warning: return type defaults to `int'
main.c:7: warning: function declaration isn't a prototype
main.c: In function `__except':
main.c:8: warning: unused variable `b'
main.c: At top level:
main.c:10: parse error before '}' token

What's your point ?

Please re-read the article I wrote. But before doing that open your
eyes, and read all of it.

My point is that MSVC doesn't get rid of its extensions even when
invoked with -Za, that should disable all extensions.

There is no sense in compiling with gcc when you want to report
a characteristic of msvc isn't it?

jacob

 

[RoSsIaCrIiLoIA]

__declspec is in the implementation name space, the compiler is allowed
to do whatever it likes with it.


__try is in the implementation name space...


__except is in the implementation name space...


Well, all the names where in the implementation name space, so the
implementation can do what it wants without diagnostics. Any
implementation could define macros like

#define __declspec(x)
#define __try
#define __except(x)

So it accepting that without diagnostics is still acceptable behaviour
according to the standard.

if it define them like C-macro or functions ok
but if they are new key words a C compiler has to compile the code?
I can not imagine __try as a function or a macro

 

[Flash Gordon]

if it define them like C-macro or functions ok
but if they are new key words a C compiler has to compile the code?
I can not imagine __try as a function or a macro

The point is that they are in the implementation name space so the
compiler can do whatever it wants once you use them. I just gave the
#defines to show that it was not necessarily changing the syntax because
you could have an implementation that passed the code successfully
without any new keywords. However, I would say that even if they are new
keywords that is still irrelevant because they are clearly in the
implementation name space and therefore for the implementation to use as
it sees fit.

<snip>

 

[Kelsey Bjarnason]

[snips]

You are entitled to your opinion, I am entitled to mine.

The difference is, his opinions are related to standard C, which is the
topic of this group, and the very reason this group was created in the
first place, while your opinions are based on something that _isn't_
standard C, therefore isn't topical here.

People get redirected from here regularly if they start posting C++
questions, or Unix-specific things, or Windows-specific things, or they
get corrected when assuming non-standard things such as 8-bit-bytes,
4-byte ints, the use of getch(), WinAPI calls and so forth, because none
of those things are part of standard C, so don't belong here. Nor do the
oddball extensions you provide, so you, also, get the suggestion to talk
about such things elsewhere.

Free speech doesn't mean that if I rent a hall, I'm required to give you
equal time; it just means that if you want to speak, you can rent your own
hall and I can't stop you. This is not your hall; if you don't like the
topics or the requirements, go rent your own hall.

 

[jacob navia]

> [snips]
> People get redirected from here regularly if they start posting C++
> questions, or Unix-specific things, or Windows-specific things, or they
> get corrected when assuming non-standard things such as 8-bit-bytes,
> 4-byte ints, the use of getch(), WinAPI calls and so forth, because none
> of those things are part of standard C, so don't belong here. Nor do the
> oddball extensions you provide, so you, also, get the suggestion to talk
> about such things elsewhere.

*I did not speak about any extensions*. My message (in answer to a user
asking for a good ide) was:

> You can download the lcc-win32 IDE+compiler without charge from
> http://www.cs.virginia.edu/~lcc-win32.

> The IDE is quite advanced, and easy to use. You have several
> wizards that allow you to get started easily.

> Welcome to C!

Where did I speak about any extensions?

Why do you attack me without reason?

Thanks for your time

jacob

 

[Randy Howard]

Where did I speak about any extensions?

Why do you attack me without reason?

It's the "boy who cried wolf" effect. You've got people convinced
now that you're just looking for ways to propose the next round
of "gee, wouldn't it be neat if we had a compiler that was CALLED
a C compiler, but was really a C++ compiler, plus a bunch of
other stuff that won't compile on any other compiler in the world?"
silliness.

IOW, you brought it on yourself. Don't give us the "woe is me"
routine.