Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #20810 > unrolled thread

A question for this group...

Back to article view | Back to comp.lang.c

Contents

  A question for this group... gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-15 17:41 +0000
    Re: A question for this group... "Chine Bleu, Russie Blanche, et Khmer Rouge" <chine.bleu@yahoo.com> - 2012-05-15 10:44 -0700
      Re: A question for this group... James Kuyper <jameskuyper@verizon.net> - 2012-05-15 14:06 -0400
    Re: A question for this group... William Ahern <william@wilbur.25thandClement.com> - 2012-05-15 13:24 -0700
      Re: A question for this group... Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-05-15 20:56 +0000
        Re: A question for this group... nick_keighley_nospam@hotmail.com - 2012-05-16 03:41 -0700
    Re: A question for this group... Old Wolf <oldwolf@inspire.net.nz> - 2012-05-16 02:31 -0700
    Re: A question for this group... nick_keighley_nospam@hotmail.com - 2012-05-16 03:53 -0700
      Re: A question for this group... gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-16 14:08 +0000
        Re: A question for this group... Martin Shobe <martin.shobe@yahoo.com> - 2012-05-16 14:49 +0000
          Re: A question for this group... Martin Shobe <martin.shobe@yahoo.com> - 2012-05-16 14:59 +0000
        Re: A question for this group... Kaz Kylheku <kaz@kylheku.com> - 2012-05-16 16:05 +0000
        Re: A question for this group... Old Wolf <oldwolf@inspire.net.nz> - 2012-05-16 14:29 -0700
      Re: A question for this group... Stephen Sprunk <stephen@sprunk.org> - 2012-05-16 18:18 -0500
    Re: A question for this group... Robert Miles <milesrf@Usenet-News.net> - 2012-06-23 23:22 -0500
    Re: A question for this group... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-25 02:41 -0700
      Re: A question for this group... gazelle@shell.xmission.com (Kenny McCormack) - 2012-06-25 16:29 +0000
        Re: A question for this group... nick_keighley_nospam@hotmail.com - 2012-06-26 08:27 -0700
          Re: A question for this group... gazelle@shell.xmission.com (Kenny McCormack) - 2012-06-27 09:05 +0000
            Re: A question for this group... nick_keighley_nospam@hotmail.com - 2012-06-27 03:57 -0700
          Re: A question for this group... Neil Cerutti <neilc@norwich.edu> - 2012-06-27 13:49 +0000
            Re: A question for this group... "io_x" <a@b.c.invalid> - 2012-06-28 09:19 +0200
              Re: A question for this group... nick_keighley_nospam@hotmail.com - 2012-06-28 01:59 -0700
                Re: A question for this group... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-28 04:18 -0700
                  Re: A question for this group... Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-06-28 12:14 +0000
                    Re: A question for this group... James Kuyper <jameskuyper@verizon.net> - 2012-06-28 08:28 -0400
                      Re: A question for this group... James Kuyper <jameskuyper@verizon.net> - 2012-06-28 08:33 -0400
                    Re: A question for this group... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-28 13:07 -0700
                      Re: A question for this group... David Thompson <dave.thompson2@verizon.net> - 2012-07-19 02:40 -0400
                Re: A question for this group... "io_x" <a@b.c.invalid> - 2012-06-28 18:58 +0200
                  Re: A question for this group... Andrew Cooper <amc96@cam.ac.uk> - 2012-06-29 01:11 +0100
                    Re: A question for this group... Philip Lantz <prl@canterey.us> - 2012-07-05 00:21 -0700
                      Re: A question for this group... nick_keighley_nospam@hotmail.com - 2012-07-06 00:24 -0700
                      Re: A question for this group... Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 17:43 -0700

Page 2 of 2 — ← Prev page 1 [2]

#22862

On 2012-06-26, nick_keighley_nospam@hotmail.com
<nick_keighley_nospam@hotmail.com> wrote:
>> >> 	Don't stick your fingers in light sockets.
>
> this is a poor analogy. We're actually talking about code like 
>
>    printf("%d %d %d",a++,a++,++a); 
>
> and the responses *aren't* "Don't Do That". Its "thats
> undefined behaviour, its outcome can't be usefyully predicted".
> IMHO analysing code like the above for a particular compiler is
> time wasted. Not just for the naive and childish poster (as you
> insist we treat them) but for anyone.

While K&R sometimes urges learners to try out different
strategies to find out what their particular implementation does
with odd constructs, e.g., Exercise 1-2, in this case they agree
with the most common responses in this newsgroup.

They give the technical reason that constructs like this are
undefined, but they further say that knowing the result of
expressions like a[i] = ++i on your implementation is, in fact,
evil.

  The moral is that writing code that depends on order of
  evaluation is a bad programming practice in any language.
  Naturally, it is necessary to know what things to avoid, but if
  you don't know how they are done on various machines you won't
  be tempted to take advantage of a particular implementation.

Do not eat of that fruit, my friends.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#22915

"Neil Cerutti" <neilc@norwich.edu> ha scritto nel messaggio
news:a50hapFhpkU2@mid.individual.net...
> On 2012-06-26, nick_keighley_nospam@hotmail.com
> <nick_keighley_nospam@hotmail.com> wrote:
>>> >> Don't stick your fingers in light sockets.
>>
>> this is a poor analogy. We're actually talking about code like
>>
>>    printf("%d %d %d",a++,a++,++a);
>>
>> and the responses *aren't* "Don't Do That". Its "thats
>> undefined behaviour, its outcome can't be usefyully predicted".
>> IMHO analysing code like the above for a particular compiler is
>> time wasted. Not just for the naive and childish poster (as you
>> insist we treat them) but for anyone.
>
> While K&R sometimes urges learners to try out different
> strategies to find out what their particular implementation does
> with odd constructs, e.g., Exercise 1-2, in this case they agree
> with the most common responses in this newsgroup.
>
> They give the technical reason that constructs like this are
> undefined, but they further say that knowing the result of
> expressions like a[i] = ++i on your implementation is, in fact,
> evil.
>
>  The moral is that writing code that depends on order of
>  evaluation is a bad programming practice in any language.
>  Naturally, it is necessary to know what things to avoid, but if
>  you don't know how they are done on various machines you won't
>  be tempted to take advantage of a particular implementation.
>
> Do not eat of that fruit, my friends.
>
> -- 
> Neil Cerutti

"yes UBs are ok...
it is question of master 1000 pages of standard for a language..."

for me, i prefer a language without UBs or if it is possible in a set
more little it is possible...

[toc] | [prev] | [next] | [standalone]

#22918

On Thursday, June 28, 2012 8:19:21 AM UTC+1, io_x wrote:

> "yes UBs are ok...
> it is question of master 1000 pages of standard for a language..."

I don't think the C standard is that large. Its a pretty slim and 
readable docuemnt (not all language standards are). An most of the 
UB is fairly obvious and that that isn't usually has a good reason.

> for me, i prefer a language without UBs 

name one. C is actually pretty good.

> or if it is possible in a set
> more little it is possible...

don't understand that.

[toc] | [prev] | [next] | [standalone]

#22925

בתאריך יום חמישי, 28 ביוני 2012 09:59:51 UTC+1, מאת nick_keigh...@hotmail.com:
> On Thursday, June 28, 2012 8:19:21 AM UTC+1, io_x wrote:
> 
> > for me, i prefer a language without UBs 
> 
> name one. C is actually pretty good.
> 
Java has no UBs. A Java program is guaranteed to produce the same output on any Java Virtual machine. The guarantee has now been weakened to accomodate different floating point processors.

[toc] | [prev] | [next] | [standalone]

#22928

On 2012-06-28, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> בתאריך יום חמישי, 28 ביוני 2012 09:59:51 UTC+1, מאת nick_keigh...@hotmail.com:
>> On Thursday, June 28, 2012 8:19:21 AM UTC+1, io_x wrote:
>> 
>> > for me, i prefer a language without UBs 
>> 
>> name one. C is actually pretty good.
>> 
> Java has no UBs. A Java program is guaranteed to produce the same
> output on any Java Virtual machine. The guarantee has now been
> weakened to accomodate different floating point processors.

There is no actual "undefined behaviour" that I know of, but that does
not mean there would not be a certain amount of platform-specific or
plain unspecified behaviour, making the "same output on any Java Virtual
machine" statement an obviously false one, even disregarding the
mentioned exception.  For example,

  System.out.println(java.io.File.separator);

is definitely not guaranteed to produce the same output on all Java
systems.

Other examples of unspecified things include exactly when, or in which
thread finalize() methods are called, exactly how threads will be
scheduled, or whether methods such as Float.valueOf(float f) (that are
specified to "cache frequently requested values") will return a new
instance or not in some particular case.  These are all observable
behaviour.

-- 
Heikki Kallasjoki

[toc] | [prev] | [next] | [standalone]

#22929

On 06/28/2012 08:14 AM, Heikki Kallasjoki wrote:
> On 2012-06-28, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
...
>> Java has no UBs. A Java program is guaranteed to produce the same
>> output on any Java Virtual machine. The guarantee has now been
>> weakened to accomodate different floating point processors.
> 
> There is no actual "undefined behaviour" that I know of, but that does
> not mean there would not be a certain amount of platform-specific or
> plain unspecified behaviour, making the "same output on any Java Virtual
> machine" statement an obviously false one, even disregarding the
> mentioned exception.  For example,
> 
>   System.out.println(java.io.File.separator);
> 
> is definitely not guaranteed to produce the same output on all Java
> systems.
> 
> Other examples of unspecified things include exactly when, or in which
> thread finalize() methods are called, exactly how threads will be
> scheduled, or whether methods such as Float.valueOf(float f) (that are
> specified to "cache frequently requested values") will return a new
> instance or not in some particular case.  These are all observable
> behaviour.

Undefined behavior is only a subset of unspecified behavior - is there
any Java construct such that the Java standard "imposes no restrictions"
on the behavior of that construct?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#22930

On 06/28/2012 08:28 AM, James Kuyper wrote:
...
> Undefined behavior is only a subset of unspecified behavior - is there
> any Java construct such that the Java standard "imposes no restrictions"
> on the behavior of that construct?

What I meant to say is that "*code with* undefined behavior is only a
subset of *code with* unspecified behavior".

The behavior permitted to code in the former category is a superset of
the behavior permitted to code in the latter category.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#22951

בתאריך יום חמישי, 28 ביוני 2012 13:14:02 UTC+1, מאת Heikki Kallasjoki:
> On 2012-06-28, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>  For example,
> 
>   System.out.println(java.io.File.separator);
> 
> is definitely not guaranteed to produce the same output on all Java
> systems.
> 
Presumably that's regarded as a class which is part of the program, rather than the program itself. If I write two methods called tan(), one of which performs the mathematical operation whilst another switches on a machine in a sun parlour, we wouldn't expect linking the two libraries to have idential results. That's true of almost every programming language.

[toc] | [prev] | [next] | [standalone]

#23389

On Thu, 28 Jun 2012 13:07:54 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

> ?????? ??? ?????, 28 ????? 2012 13:14:02 UTC+1, ??? Heikki Kallasjoki:
> > On 2012-06-28, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> >  For example,
> > 
> >   System.out.println(java.io.File.separator);
> > 
> > is definitely not guaranteed to produce the same output on all Java
> > systems.
> > 
> Presumably that's regarded as a class which is part of the program, 
> rather than the program itself. If I write two methods called tan(),
> one of which performs the mathematical operation whilst another
> switches on a machine in a sun parlour, we wouldn't expect linking the
> two libraries to have idential results. That's true of almost every
> programming language.

I'm not sure what 'class which is part of the program, rather than the
program itself' is intended to mean. All Java packages with first
component java or javax, and classes in them such as java.io.File
here, are reserved for definition by Sun^WOracle. System is actually
java.lang.System (because java.lang is automatically visible in all
Java code, unlike all other packages) and thus similarly standard.
Most java.* packages are part of the (JRE) standard library and thus
usable from any Java code; since Java is dynamically linked, a
complete program can only be defined sensibly as a main routine and
everything its execution can -- or more strictly, does -- access.

In C and some older compiled languages there is a global namespace for
'external' (in C, non-static) routines and variables, so yes two
different 'tan's can be a problem. C++ has namespaces which can be
used to disambiguate, but IME people rarely do. Fortran>=90 has
one-level modules, but it's not clear to me how much they are used; a
lot of Fortran code is 'dusty decks' from long before 1990.

Ada and Java have hierarchical package naming, which people do use.
The two tan's in your example would actually be something like:
org.mathlovers.Trigonometry.tan
com.New_You_483.Farrah.tan
and Java the full 'path' is in the .class file and used for dynamic
linking at runtime to get the correct one.

Some languages allow overloads of routines/methods with different
parameter lists. Java distinguishes these in the .class file; C++
typically uses mangled linker names (though the standard doesn't
specify); Ada usually needs a special or modified linker anyway and
can also resolve on expected return type. (Fortran>=90 allows you to
user-define generic names which call different routines depending on
argument types, but those 'specific' routines do have unique names --
although possibly 'private' ones you can't directly use in a call.)

So java.io.File.separator is always, on every valid JVM, a specific
Suncle-defined variable with a platform-dependent value which is in
fact different on different JVMs, falsifying your overbroad claim.
What *is* standard across all platforms in Java is the core language
-- e.g. int arithmetic is 32-bit 2's-complement with wraparound --
except as you said (almost) floating-point in the absence of strictfp;
and a large fraction of the standard library (up to resource limits,
and there Java is at least safe, unlike some C implementations).

Java also has a fair chunk of library functionality altered by locale
(e.g. character encoding, date-time format) or timezone; so does C
(and C++). This is a grey area that makes 'strictly conforming' even
more useless, since it produces different results even on machines of
the same type or users on the same machine, which are intended to be
and usually(?) are all correct.

[toc] | [prev] | [next] | [standalone]

#22936

<nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:1df54e49-511e-4dc7-bb7a-ed23cf6a7d25@googlegroups.com...
> On Thursday, June 28, 2012 8:19:21 AM UTC+1, io_x wrote:
>
>> "yes UBs are ok...
>> it is question of master 1000 pages of standard for a language..."
>
> I don't think the C standard is that large. Its a pretty slim and
> readable docuemnt (not all language standards are). An most of the
> UB is fairly obvious and that that isn't usually has a good reason.
>
>> for me, i prefer a language without UBs
>
> name one. C is actually pretty good.

x86 32bit assembly

>> or if it is possible in a set
>> more little it is possible...
>
> don't understand that.

less UBs there are, better it is...

[toc] | [prev] | [next] | [standalone]

#22957

On 28/06/2012 17:58, io_x wrote:
> <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
> news:1df54e49-511e-4dc7-bb7a-ed23cf6a7d25@googlegroups.com...
>> On Thursday, June 28, 2012 8:19:21 AM UTC+1, io_x wrote:
>>
>>> "yes UBs are ok...
>>> it is question of master 1000 pages of standard for a language..."
>>
>> I don't think the C standard is that large. Its a pretty slim and
>> readable docuemnt (not all language standards are). An most of the
>> UB is fairly obvious and that that isn't usually has a good reason.
>>
>>> for me, i prefer a language without UBs
>>
>> name one. C is actually pretty good.
> 
> x86 32bit assembly

Pure 32bit assembly perhaps, but as soon as you introduce more than 1
processor, there is plenty of undefined and unpredictable behaviour to
be had.

~Andrew

> 
>>> or if it is possible in a set
>>> more little it is possible...
>>
>> don't understand that.
> 
> less UBs there are, better it is...
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#23086

io_x wrote:
> nick_keighley ha scritto...
>> io_x wrote:
>>> for me, i prefer a language without UBs
>>
>> name one. C is actually pretty good.
> 
> x86 32bit assembly

If a repeat prefix is used with an instruction other than MOVS, CMPS, 
SCAS, LODS, STOS, INS, or OUTS, the behavior is undefined.

If the source operand of BSF is 0, the result is undefined.

If the BSWAP instruction references a 16-bit register, the result is 
undefined.

If the value of the source operand of F2XM1 is outside the range -1.0 to 
+1.0, the result is undefined.

...

[toc] | [prev] | [next] | [standalone]

#23103

On Thursday, July 5, 2012 8:21:07 AM UTC+1, Philip Lantz wrote:
> io_x wrote:
> > nick_keighley ha scritto...
> >> io_x wrote:


> >>> for me, i prefer a language without UBs
> >>
> >> name one. C is actually pretty good.
> > 
> > x86 32bit assembly
> 
> If a repeat prefix is used with an instruction other than MOVS, CMPS, 
> SCAS, LODS, STOS, INS, or OUTS, the behavior is undefined.
> 
> If the source operand of BSF is 0, the result is undefined.
> 
> If the BSWAP instruction references a 16-bit register, the result is 
> undefined.
> 
> If the value of the source operand of F2XM1 is outside the range -1.0 to 
> +1.0, the result is undefined.
> 
> ...

so io_x doesn't even know much about x86 assembler...

[toc] | [prev] | [next] | [standalone]

#23125

Philip Lantz <prl@canterey.us> writes:

> io_x wrote:
>> nick_keighley ha scritto...
>>> io_x wrote:
>>>> for me, i prefer a language without UBs
>>>
>>> name one. C is actually pretty good.
>> 
>> x86 32bit assembly
>
> If a repeat prefix is used with an instruction other than MOVS, CMPS, 
> SCAS, LODS, STOS, INS, or OUTS, the behavior is undefined.
>
> If the source operand of BSF is 0, the result is undefined.
>
> If the BSWAP instruction references a 16-bit register, the result is 
> undefined.
>
> If the value of the source operand of F2XM1 is outside the range -1.0 to 
> +1.0, the result is undefined.

I confess I'm not an expert on the fine points of x86
instruction architecture, but it seems likely that these
examples produce indeterminate results rather than truly
being undefined behavior.  For example, probably all of them
are guaranteed not to leave virtual mode, regardless of
whatever else may happen.  That may not be much of a
restriction, but any restiction means it's not undefined
behavior.

Incidentally, defining an opcode as "reserved for future
use", then defining it in a later family, is also something
I would not count as undefined behavior.  It is _always_
true for any defined behavior that it might be changed in a
future revision of the defining document;  that doesn't mean
the behavior is undefined, only that a future revision is
free to redefine (or semi-define, or even undefine) it.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web