level of questions for experts only

[Mike Wahler]

Depends what you mean. My computer is physically incapable of
producing "undefined" byte values, so my source code is always
well-defined. Of course, if one of my programs violates a
constraint, then my C compiler issues a diagnostic and refuses
to compile the code, as required and allowed, respectively, by
the Standard. So there does not exist any "program", nor any
"behavior", defined or otherwise, associated with a program
which is not correct C. IMHO.


'Course not! The error would specify (if I'm lucky) which
constraint had been violated, so I could fix it.


That doesn't make sense. A "C program" which does not compile
is not, technically speaking, a C program. It's *almost* a
program, but if it's not something that a C compiler can accept,
then I wouldn't call it a C program. And in this newsgroup, we
only talk about the "(un)defined behavior" of C programs.


Did you? Sorry.


How does that invoke UB?

6.4 Lexical elements

Constraints

2 Each preprocessing token that is converted to a token shall
have the lexical form of a keyword, an identifier, a constant,
a string literal, or a punctuator.

Semantics

3 A token is the minimal lexical element of the language in
translation phases 7 and 8. The categories of tokens are:
keywords, identifiers, constants, string literals, and
punctuators. A preprocessing token is the minimal lexical
element of the language in translation phases 3 through 6.
The categories of preprocessing tokens are: header names,
identifiers, preprocessing numbers, character constants,
string literals, punctuators, and single non-white-space
characters that do not lexically match the other preprocessing
token categories. If a ' or a " character matches the last
category, the behavior is undefined. Preprocessing tokens <<<=====
can be separated by white space; this consists of comments
(described later), or white-space characters (space, horizontal
tab, new-line, vertical tab, and form-feed), or both. As
described in 6.10, in certain circumstances during translation
phase 4, white space (or the absence thereof) serves as more
than preprocessing token separation. White space may appear
within a preprocessing token only as part of a header name
or between the quotation characters in a character constant
or string literal.

In fact, how exactly does that violate
a constraint?

AFAICT it doesn't.

I'm having a hard time reading the Standard tonight;
I know there's some prohibition about unterminated character constants
in there somewhere, but I can't find it...

See above.

-Mike

 

[pete]

On Sun, 28 Sep 2003, Peter Nilsson wrote:

... an implementation is NEVER required to diagnose
undefined behavior.
I decided to explain (rather poorly as it seems) that certain forms of
undefined behaviour do indeed *require* a diagnostic. [printf format
specifiers are not part of that list though.]
If you can come up with a construction which exhibits both a
constraint violation *and* undefined behavior, as part of the
same construct (I'm not really sure what that means anyway),
or an example of undefined behavior that requires a diagnostic,
then I'll have learned something. But AFAIK constraint violations
are one thing and undefined behavior is another thing, and never
the twain shall meet.

int array[1], *pointer = (char*)array;

Sorry, pete, I don't get it. Is the above undefined or
incorrect in some way?

N869
6.5.16.1 Simple assignment
Constraints
[#1] One of the following shall hold:
-- the left operand has qualified or unqualified
arithmetic type and the right has arithmetic type;
-- the left operand has a qualified or unqualified version
of a structure or union type compatible with the type
of the right;

-- both operands are pointers to qualified or unqualified
versions of compatible types, and the type pointed to
by the left has all the qualifiers of the type pointed
to by the right;
-- one operand is a pointer to an object or incomplete
type and the other is a pointer to a qualified or
unqualified version of void, and the type pointed to by
the left has all the qualifiers of the type pointed to
by the right; or
-- the left operand is a pointer and the right is a null
pointer constant.
-- the left operand has type _Bool and the right is a
pointer.

 

[Chris Dollin]

response if u ,on all level of questions:::

I am not a comma.

1.how a self deletable .exe file deleted on some future date & time
without
invoking the .exe itself?

This is not a C question.

2.if we want that any wildcard characters in command line arguments
should be appropriately expanded,are we reqd. 2 make any special
provision?if yes,which?

This is not an implementation-independant C question.

3.why :: printf("%%%%%") ; output %%%.

Probably a bug in the run-time support.

4.how 2 run a .obj file without previously creating any .exe?

This is not a C question.

5.what is classical class?(FOR C++)

This is not a C question, and it's not a C++ question either, but
one answer is, it's a class for the teaching of classics.

Why not post non-C questions to non-C newsgroups ... *please*?

 

[CBFalconer]

Now *that* is the way to get folks to help you.

How come you haven't PLONKED it? If it never gets any responses
it will eventually go away.

 

[Arthur J. O'Dwyer]

[re: ROSY]
Now *that* is the way to get folks to help you.

How come you haven't PLONKED it? If it never gets any responses
it will eventually go away.

IMHO, ignoring ignorant-type trolls (as opposed to joyriding-type
trolls) often doesn't help. And I do take exception to the many
posters in this thread who respond publicly *only* to quote all
or part of the message, followed by "*PLONK*". That doesn't do
anything useful, guys. If we wanted to know the minutiae of your
client-side filtering system, we'd read your blog. Just plonk
quietly and move on, please.

As for me, I'm enjoying ROSY's colloquy. I particularly like the
mental imagery associated with the repeated idiom "spoke ur nose",
and the Babylonian-l33tsp33k effect of "R u harlot!!!" is really
masterful. You guys don't know what you're missing.

-Arthur

 

[Peter Nilsson]

"C programs" with constraint violations: do not compile,

Chapter and Verse please.

Every one of my compilers successfully translates...

unsigned char *p = 0xFFFE;

The #error directive (not excluded by #if) is the *only* construct in
which an implementation *must* fail to translate a program.

You have heard that Fortran programs are conforming C programs,
haven't you?

The failure to translate a program to an executable is the most common
form of undefined behaviour, but like every other form undefined
behaviour, it is not a general *requirement*.

thus are not *really* written in C.

<sigh>

You'll have to define what YOU mean by a "real" C program. A
'conforming' program can be pretty much anything. Implementations
would have a hard time selling to the commercial world if they could
only translate strictly conforming programs.

 

[CBFalconer]

[re: ROSY]
Now *that* is the way to get folks to help you.

How come you haven't PLONKED it? If it never gets any responses
it will eventually go away.

IMHO, ignoring ignorant-type trolls (as opposed to joyriding-type
trolls) often doesn't help. And I do take exception to the many
posters in this thread who respond publicly *only* to quote all
or part of the message, followed by "*PLONK*". That doesn't do
anything useful, guys. If we wanted to know the minutiae of your
client-side filtering system, we'd read your blog. Just plonk
quietly and move on, please.

My reasoning is that it should at least know its being PLONKED.
It may eventually find out what that means. I then have no
further urge to clutter the newsgroup.

As for me, I'm enjoying ROSY's colloquy. I particularly like the
mental imagery associated with the repeated idiom "spoke ur nose",
and the Babylonian-l33tsp33k effect of "R u harlot!!!" is really
masterful. You guys don't know what you're missing.

IIRC it (ROSY) was originally posting cross-posted. Maybe t'other
newsgroup is more suitable for your amusement? I'm sure it is not
hard to excite ROSY.

I am not trying to start any argument. Just stating views.

 

[Richard Heathfield]

Chapter and Verse please.

Every one of my compilers successfully translates...

unsigned char *p = 0xFFFE;

The #error directive (not excluded by #if) is the *only* construct in
which an implementation *must* fail to translate a program.

I'm not convinced that the implementation /must/ fail to translate a program
under this circumstance. Do you have C&V?

The closest I can find is this:

"A preprocessing directive of the form

# error pp-tokens<opt> new-line

causes the implementation to produce a diagnostic message that includes the
specified sequence of preprocessing tokens."

Nothing there about terminating the program. What did I miss?

 

[Keith Thompson]

Peter Nilsson wrote: [...]

The #error directive (not excluded by #if) is the *only* construct in
which an implementation *must* fail to translate a program.

I'm not convinced that the implementation /must/ fail to translate a program
under this circumstance. Do you have C&V?

The closest I can find is this:

"A preprocessing directive of the form

# error pp-tokens<opt> new-line

causes the implementation to produce a diagnostic message that includes the
specified sequence of preprocessing tokens."

Nothing there about terminating the program. What did I miss?

Section 4 (Conformance), paragraph 4:

The implementation shall not successfully translate a
preprocessing translation unit containing a #error preprocessing
directive unless it is part of a group skipped by conditional
inclusion.

 

[Minti]

hello,
response if u ,on all level of questions:::
1.how a self deletable .exe file deleted on some future date & time
without
invoking the .exe itself?

2.if we want that any wildcard characters in command line arguments
should be appropriately expanded,are we reqd. 2 make any special
provision?if yes,which?
3.why :: printf("%%%%%") ; output %%%.
4.how 2 run a .obj file without previously creating any .exe?
5.what is classical class?(FOR C++)

bye,

When I first checked out the heading of your thread. I thought better
stay out of this iman, you haven't coded much since long time and you
might end up making a fool out of yourself. Well after reading it I
know it was the other way around thanks for helping me make me a
confident man again. You did what Oprah could not do.

Please read the FAQ before you post to a group. Many groups have it
c.l.c also has it.

BTW I have a reason to belive this is your first "expert job
assignment at ISRO".

--
Imanpreet Singh Arora
imanpreet_arora AT yahoo DOT co DOT in

What I can't create, I can't understand.
-- Richard Feynman

 

[Dan Pop]

Chapter and Verse please.

Every one of my compilers successfully translates...

unsigned char *p = 0xFFFE;

I wouldn't say that a translation that has generated a mandatory
diagnostic qualifies as successful: the standard doesn't guarantee
*anything* at all about the generated code. And, as far as I know,
the compilers' documentation provides no guarantees, either.

<sigh>

You'll have to define what YOU mean by a "real" C program.

That's easy: a program that doesn't require any diagnostic and that
doesn't invoke any form of undefined behaviour that can be detected at
translation time.

I prefer the term "correct C program", as defined by C99, which is a bit
more restrictive.

Dan

 

[Arthur J. O'Dwyer]

[because producing a diagnostic doesn't guarantee anything
about the contents of any executable that might be produced]

That's easy: a program that doesn't require any diagnostic and that
doesn't invoke any form of undefined behaviour that can be detected at
translation time.

I must here disagree with Dan; I'd rather keep my definition,
because the concept of "UB that can be detected at translation time"
is almost certainly not well-defined. OTOH, the Standard quite
*clearly* defines what it means by "constraint violation" (as far
as I can tell), so it's quite obvious whether any particular
program contains a constraint violation or not.

I would call code demonstrating UB a "bad C program" -- but still
a C program, just one without well-defined results when executed.
In other words, it's a C program which is *not* a *correct* C
program, as you say below.

I prefer the term "correct C program", as defined by C99, which
is a bit more restrictive.

True. I bet that determining whether a given program is correct
given only its source code is undecidable, though, so that's not
a very good definition for use by compilers.

-Arthur

 

[Peter Nilsson]

I'm not convinced that the implementation /must/ fail to translate a program
under this circumstance. Do you have C&V?

C99 4p4:

The implementation shall not successfully translate a preprocessing
translation unit containing a #error preprocessing directive unless
it is part of a group skipped by conditional inclusion.

 

[Dave Thompson]

On Sun, 28 Sep 2003 12:51:19 -0400 (EDT)

int array[1], *pointer = (char*)array;

Sorry, pete, I don't get it. Is the above undefined or
incorrect in some way?

array is an array of ints which is being cast to a char*
*pointer is a pointer to an int which is having a pointer to char
assigned to it.

IIRC you are not allowed to assign a pointer to char to another pointer
type without a cast and I don't think the conversion from int* -> char*
-> int* is guaranteed.
[/QUOTE]
Correct you can't implicitly convert, and hence assign, pass, return,
or initialize without cast, char* to any other data pointer *except*
void*. (Plus qualification as needed; that's orthogonal to type.)

With cast, the result is guaranteed for char (or void). 6.3.2.3p7:
A pointer to an object or incomplete type may be converted to a
pointer to a different
object or incomplete type. If the resulting pointer is not correctly
aligned57) for the
pointed-to type, the behavior is undefined. Otherwise, when converted
back again, the
result shall compare equal to the original pointer. <snip>

Plus the fact that every object (hence every valid object pointer)
must be sufficiently aligned for character types (and void pointers),
but this is not required for any other data type. And that nonnull
data pointers compare equal iff they point to the same object, or the
special and problematic case &just_past_a == &b, but that shouldn't
apply here.

- David.Thompson1 at worldnet.att.net