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

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

linking precedence rules

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

Contents

  linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-07 23:49 -0800
    Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-08 21:20 +1300
      Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-08 01:32 -0800
        Re: linking precedence rules "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 11:08 -0500
          Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-12 03:25 -0800
            Re: linking precedence rules Noob <root@127.0.0.1> - 2017-01-12 13:31 +0100
              OT Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-14 01:18 -0800
        Re: linking precedence rules Barry Schwarz <schwarzb@dqel.com> - 2017-01-08 15:38 -0800
          Re: linking precedence rules "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 18:46 -0500
          Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-12 04:13 -0800
            Re: linking precedence rules Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 12:21 +0000
              Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 00:23 -0800
                Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-16 06:20 -0800
                  Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:10 -0800
                Re: linking precedence rules Manfred <noname@invalid.add> - 2017-02-04 17:12 +0100
                  Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 20:47 -0800
            Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-12 13:31 +0000
              Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-13 01:58 -0800
                Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:41 +0000
                  Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-14 03:49 -0800
                    Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 12:03 +0000
                      Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 14:02 +0100
                        Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 13:46 +0000
                          Re: linking precedence rules gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-14 14:23 +0000
                          Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:31 +0000
                            Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 16:18 +0000
                              Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 17:49 +0100
                                Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 17:21 +0000
                                  Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:12 +1300
                                    Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 21:59 +0000
                                      Re: linking precedence rules supercat@casperkitty.com - 2017-01-14 14:12 -0800
                                      Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-15 11:39 +1300
                                        Re: linking precedence rules Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 16:03 -0800
                                          Re: linking precedence rules raltbos@xs4all.nl (Richard Bos) - 2017-01-18 11:51 +0000
                                    Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-15 02:04 -0800
                                  Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 23:48 +0100
                              Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 20:28 +0000
                      The Unix way vs. the Windows way (Was: linking precedence rules) gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-14 14:14 +0000
                        Re: The Unix way vs. the Windows way (Was: linking precedence rules) BartC <bc@freeuk.com> - 2017-01-14 14:29 +0000
                        Re: The Unix way vs. the Windows way (Was: linking precedence rules) supercat@casperkitty.com - 2017-01-14 14:20 -0800
                      Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-15 01:40 -0800
                        Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-15 11:43 +0000
                      Re: linking precedence rules antispam@math.uni.wroc.pl - 2017-01-18 19:55 +0000
                    Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:22 +0000
                Re: comparison logic Noob <root@127.0.0.1> - 2017-01-13 16:05 +0100
                  Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 15:37 +0000
                  Re: comparison logic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 16:06 +0000
                    Re: comparison logic Noob <root@127.0.0.1> - 2017-01-13 19:37 +0100
                      Re: comparison logic BartC <bc@freeuk.com> - 2017-01-13 18:42 +0000
                      Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:49 +0000
                      Re: comparison logic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 20:50 +0000
                        Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 01:05 -0800
                          Re: comparison logic Michael Holiday <Mike@example.invalid> - 2017-01-14 01:27 -0800
                          Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-14 13:56 -0800
                            Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 14:45 +0000
                            Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:42 -0800
                              Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-15 21:04 -0800
                                Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 04:47 -0800
                                  Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-30 11:40 -0800
                                    Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 16:42 -0800
                                      Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-03 18:45 -0800
                                        Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:03 -0800
                                          Re: comparison logic supercat@casperkitty.com - 2017-02-09 08:07 -0800
                                            Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 08:50 -0800
                                              Re: comparison logic supercat@casperkitty.com - 2017-02-09 12:15 -0800
                                                Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 12:38 -0800
                                                  Re: comparison logic supercat@casperkitty.com - 2017-02-09 14:13 -0800
                                                    Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 14:45 -0800
                                            Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 10:20 -0800
            Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-12 14:32 +0000
            Re: linking precedence rules James Kuyper <jameskuyper@verizon.net> - 2017-01-12 13:33 -0500

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#101837

On 1/14/2017 4:03 AM, BartC wrote:
> On 14/01/2017 11:49, Michael Holiday wrote:
>
>> I disagree with you that my mingw install is broken. The one I'm trying
>> to link to is hot off the presses, but there's 3 others on this machine
>> that have altered paths and the like. One less tonight. What strikes me
>> is how different they are in their architecture.
>
> If you have more than one version of gcc on a Windows machine, my
> experience is that they will clash with each other.
>
> You would think that, if you start the main executable from a place like
> c:\gcc\bin\gcc.exe, that it would look for associated files in the same
> location or using a relative path from that location. But gcc favoured
> searching through all the PATH paths until it found a file with the
> right name. Never mind that it belonged to a different version or even a
> different application!
>

I think that happened here. So my path variable looks like Kanye West's 
chain of fools:

C:\Users\Fred\Documents>path
PATH=C:\ProgramData\Oracle\Java\javapath;C:\Perl\site\bin;C:\Perl\bin;C:\Program 
Files\Broadcom\Broadcom 802.11 Network Adapter\Driver;;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS 
Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program 
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program 
Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files 
(x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files 
(x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files 
(x86)\Intel\OpenCL SDK\2.0\bin\x86;C:\Program Files (x86)\Intel\OpenCL 
SDK\2.0\bin\x64;C:\Program Files\Microsoft SQL 
Server\110\Tools\Binn\;C:\Program Files\Java\jdk1.7.0_21\bin;C:\Program 
Files 
(x86)\QuickTime\QTSystem\;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\Program 
Files (x86)\Skype\Phone\;C:\Program Files (x86)\Windows Kits\10\Windows 
Performance 
Toolkit\;C:\Users\Fred\Documents\perl5\bin;C:\Users\Fred\perl5\bin;C:\Ruby21-x64\bin;C:\Users\Fred\AppData\Local\Microsoft\WindowsApps;C:\MinGW\bin

I deleted the perl install  at C:\Perl\site\bin; and C:\Perl\bin; . 
These are guaranteed to have C compilers as perl is implemented in C.

Although the entry for that rogue perl install is still in the path and 
recent, dammit, 2/3 down the way one sees:

C:\Strawberry\c\bin;

This is where gcc was supposed to be processed, so I have an idea why my 
install is wonky. I thought it was cleaner and newer than all this.

Tried the band-aid measure of setting the path, but that won't do:

C:\Users\Fred\Documents>>SET PATH=%PATH%;C:\MinGW\bin

C:\Users\Fred\Documents>path
PATH=C:\ProgramData\Oracle\Java\javapath;C:\Perl\site\bin;C:\Perl\bin;C:
...
C:\MinGW\bin;C:\MinGW\bin

I used to just plow under my os at this point and start over, but I lack 
all kinds of things to pull that off, like a system disc and a reliable 
disc reader.

I'm gonna see what happens when I make fundamental changes to this as 
well as LIBRARY_PATH.
-- 
Michael

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

#101841

On 15/01/2017 09:40, Michael Holiday wrote:
> On 1/14/2017 4:03 AM, BartC wrote:

> But gcc favoured
>> searching through all the PATH paths until it found a file with the
>> right name. Never mind that it belonged to a different version or even a
>> different application!
>>
>
> I think that happened here. So my path variable looks like Kanye West's
> chain of fools:
>
> C:\Users\Fred\Documents>path
> PATH=C:\ProgramData\Oracle\Java\javapath;C:\Perl\site\bin;C:\Perl\bin;C:\Program
...
> I deleted the perl install  at C:\Perl\site\bin; and C:\Perl\bin; .
> These are guaranteed to have C compilers as perl is implemented in C.

I had the same problem myself yesterday. I renamed the location of my 
gcc installation for testing something, but gcc still worked if I typed 
it anywhere. But it was version 2.95 instead of 5.1.0.

It turned out I had six different versions altogether! Mostly these were 
compilers that were bundled with other products, which someone wouldn't 
even be aware about. (That answers the question of why someone would 
have more than one version; the decision is out of their hands.)

I found them by doing 'dir gcc.exe/s' while at the \ directory.

-- 
Bartc

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

#102146

BartC <bc@freeuk.com> wrote:
> On 14/01/2017 11:49, Michael Holiday wrote:
> 
> > I disagree with you that my mingw install is broken. The one I'm trying
> > to link to is hot off the presses, but there's 3 others on this machine
> > that have altered paths and the like. One less tonight. What strikes me
> > is how different they are in their architecture.
> 
> If you have more than one version of gcc on a Windows machine, my 
> experience is that they will clash with each other.
> 
> You would think that, if you start the main executable from a place like 
> c:\gcc\bin\gcc.exe, that it would look for associated files in the same 
> location or using a relative path from that location. But gcc favoured 
> searching through all the PATH paths until it found a file with the 
> right name. Never mind that it belonged to a different version or even a 
> different application!

I can not say what Windows build is doing, but in general gcc contains
hardcoded paths to its components and it will use components from
there.  There is also logic to handle relative paths.  In general
gcc will _not_ look up its components in the PATH: PATH is for
user level programs and gcc components are supposed to be used
via front-end programs (which may be or may be not in the PATH).
Note that hardcoded paths contain embeded vesion number, for
example on my machine gcc components are in:

/usr/lib/gcc/x86_64-linux-gnu/4.9

Different version will use different location so there would
be no conflict.  Only if you want to use two "versions"
of the same version you may run into trouble.

gcc may look in the PATH for independent programs that it needs,
namely for linker and assembler.  This is resonable if gcc
is configured to use system linker and assembler: in such
case they are supposed to be available in the PATH.

Note that several things about gcc are configurable by person
compiling gcc.  AFAIK mingw port is additionaly patched.
So if you are using mingw binary complain to mingw maintainers
for bad configuration values.

-- 
                              Waldek Hebisch

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

#101761

Michael Holiday <Mike@example.invalid> writes:

> On 1/13/2017 2:41 AM, Ben Bacarisse wrote:
>> Michael Holiday <Mike@example.invalid> writes:
<snip>
>>> The above is completely-standard C. How do I get this thing hooked up right?
>>
>> You need to find out somewhere to ask that will find people who use
>> mingw.  It looks like something in your installation is broken.  Simple
>> program should be simple to compile (and indeed they were the few times
>> I ever used mingw).
>>
>
> I searched for mingw and windowsy-sounding places on usenet and didn't
> get much from the forum I posted on. I wasn't intending to make a
> career out of this. I'd be glad to hear of any ng's where gcc or mingw
> were more topical.

The issue is much more a mingw one than a gcc one.

> I disagree with you that my mingw install is broken.

OK.  But for the code you posted, no special flags should be needed to
get the program to compile.  That makes it look broken from here.

> The one I'm
> trying to link to is hot off the presses, but there's 3 others on this
> machine that have altered paths and the like.

Ah...  That may be significant.  I would have only one if at all
possible.

<snip>
-- 
Ben.

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

#101608 — Re: comparison logic

On 13/01/2017 10:58, Michael Holiday wrote:

> void diff_line( char *lineone, char *linetwo, int linenumber )
> {
>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)

(a < 0) || (a > 0) is strictly equivalent to a != 0

I would use the latter.

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

#101609 — Re: comparison logic

On 13/01/17 15:05, Noob wrote:
> On 13/01/2017 10:58, Michael Holiday wrote:
>
>> void diff_line( char *lineone, char *linetwo, int linenumber )
>> {
>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>
> (a < 0) || (a > 0) is strictly equivalent to a != 0
>
> I would use the latter.

So would I, in this case. More generally, if I wanted to call an 
information function such as strcmp, strlen, etc more than once on the 
same data, I would cache the result. I'll use the above example to 
illustrate this, even though (as you rightly say) in this case you 
wouldn't do it like this because you can compare != 0.

int diff = strcmp(lineone, linetwo);
if(diff < 0 || diff > 0)

Obviously in this case there's no need because you'd just do != 0 
instead. But it matters in cases like this:

for(i = 0; i < strlen(s); i++) /* NO! */
{
   dosomethingwith(s[i]);
}

where it is better to do this:

size_t len = strlen(s);
for(i = 0; i < len; i++)
{
   dosomethingwith(s[i]);
}

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#101612 — Re: comparison logic

Noob <root@127.0.0.1> writes:

> On 13/01/2017 10:58, Michael Holiday wrote:
>
>> void diff_line( char *lineone, char *linetwo, int linenumber )
>> {
>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>
> (a < 0) || (a > 0) is strictly equivalent to a != 0

I'm not sure what you intend by "strictly equivalent" but they are
different in that `a` may be evaluated more than once (and, though not
relevant here) they are different when `a` is a floating point NaN.

> I would use the latter.

Agreed, though I sometimes use plain `a` if the context means that makes
sense.

-- 
Ben.

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

#101640 — Re: comparison logic

On 13/01/2017 17:06, Ben Bacarisse wrote:

> Noob <root@127.0.0.1> writes:
> 
>> On 13/01/2017 10:58, Michael Holiday wrote:
>>
>>> void diff_line( char *lineone, char *linetwo, int linenumber )
>>> {
>>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>>
>> (a < 0) || (a > 0) is strictly equivalent to a != 0
> 
> I'm not sure what you intend by "strictly equivalent" but they are
> different in that `a` may be evaluated more than once (and, though not
> relevant here) they are different when `a` is a floating point NaN.

I meant: for all possible values of int variable 'i'
((i < 0) || (i > 0)) and (i != 0) are equal.

> Agreed, though I sometimes use plain `a` if the context means that makes
> sense.

Are you saying that 'a' is a bad name for an int variable?

Regards.

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

#101642 — Re: comparison logic

On 13/01/2017 18:37, Noob wrote:
> On 13/01/2017 17:06, Ben Bacarisse wrote:
>
>> Noob <root@127.0.0.1> writes:
>>
>>> On 13/01/2017 10:58, Michael Holiday wrote:
>>>
>>>> void diff_line( char *lineone, char *linetwo, int linenumber )
>>>> {
>>>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>>>
>>> (a < 0) || (a > 0) is strictly equivalent to a != 0
>>
>> I'm not sure what you intend by "strictly equivalent" but they are
>> different in that `a` may be evaluated more than once (and, though not
>> relevant here) they are different when `a` is a floating point NaN.
>
> I meant: for all possible values of int variable 'i'
> ((i < 0) || (i > 0)) and (i != 0) are equal.
>
>> Agreed, though I sometimes use plain `a` if the context means that makes
>> sense.
>
> Are you saying that 'a' is a bad name for an int variable?

I think he means:

   if (a)

rather than:

   if (a != 0)

or:

   if (a<0 || a>0)

But in the context of strcmp, then:

   if (strcmp(s, t))

might not be that clear; are they testing for inequality, or testing for 
equality and forgot to compare with 0? Always doing an explicit test 
might be better.

-- 
Bartc

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

#101647 — Re: comparison logic

On 13/01/17 18:37, Noob wrote:
> On 13/01/2017 17:06, Ben Bacarisse wrote:
>
>> Noob <root@127.0.0.1> writes:
>>
>>> On 13/01/2017 10:58, Michael Holiday wrote:
>>>
>>>> void diff_line( char *lineone, char *linetwo, int linenumber )
>>>> {
>>>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>>>
>>> (a < 0) || (a > 0) is strictly equivalent to a != 0
>>
>> I'm not sure what you intend by "strictly equivalent" but they are
>> different in that `a` may be evaluated more than once (and, though not
>> relevant here) they are different when `a` is a floating point NaN.
>
> I meant: for all possible values of int variable 'i'
> ((i < 0) || (i > 0)) and (i != 0) are equal.
>
>> Agreed, though I sometimes use plain `a` if the context means that makes
>> sense.
>
> Are you saying that 'a' is a bad name for an int variable?

No, he's saying that if(a != 0) is equivalent to if(a)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#101660 — Re: comparison logic

Noob <root@127.0.0.1> writes:

> On 13/01/2017 17:06, Ben Bacarisse wrote:
>
>> Noob <root@127.0.0.1> writes:
>> 
>>> On 13/01/2017 10:58, Michael Holiday wrote:
>>>
>>>> void diff_line( char *lineone, char *linetwo, int linenumber )
>>>> {
>>>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>>>
>>> (a < 0) || (a > 0) is strictly equivalent to a != 0
>> 
>> I'm not sure what you intend by "strictly equivalent" but they are
>> different in that `a` may be evaluated more than once (and, though not
>> relevant here) they are different when `a` is a floating point NaN.
>
> I meant: for all possible values of int variable 'i'
> ((i < 0) || (i > 0)) and (i != 0) are equal.

Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
resit nit-picking.)

-- 
Ben.

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

#101727 — Re: comparison logic

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Noob <root@127.0.0.1> writes:
>
>> On 13/01/2017 17:06, Ben Bacarisse wrote:
>>
>>> Noob <root@127.0.0.1> writes:
>>>
>>>> On 13/01/2017 10:58, Michael Holiday wrote:
>>>>
>>>>> void diff_line( char *lineone, char *linetwo, int linenumber )
>>>>> {
>>>>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>>>>
>>>> (a < 0) || (a > 0) is strictly equivalent to a != 0
>>>
>>> I'm not sure what you intend by "strictly equivalent" but they are
>>> different in that `a` may be evaluated more than once (and, though not
>>> relevant here) they are different when `a` is a floating point NaN.
>>
>> I meant:  for all possible values of int variable 'i'
>> ((i < 0) || (i > 0)) and (i != 0) are equal.
>
> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
> resit nit-picking.)

I think there is a second-order nit-picking rule in play here,
analogous to the rule about pointing out a spelling correction.
(yes, I can't resit either.)

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

#101729 — Re: comparison logic

On 1/14/2017 1:05 AM, Tim Rentsch wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Noob <root@127.0.0.1> writes:
>>
>>> On 13/01/2017 17:06, Ben Bacarisse wrote:
>>>
>>>> Noob <root@127.0.0.1> writes:
>>>>
>>>>> On 13/01/2017 10:58, Michael Holiday wrote:
>>>>>
>>>>>> void diff_line( char *lineone, char *linetwo, int linenumber )
>>>>>> {
>>>>>>    if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
>>>>>
>>>>> (a < 0) || (a > 0) is strictly equivalent to a != 0
>>>>
>>>> I'm not sure what you intend by "strictly equivalent" but they are
>>>> different in that `a` may be evaluated more than once (and, though not
>>>> relevant here) they are different when `a` is a floating point NaN.
>>>
>>> I meant:  for all possible values of int variable 'i'
>>> ((i < 0) || (i > 0)) and (i != 0) are equal.
>>
>> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
>> resit nit-picking.)
>
> I think there is a second-order nit-picking rule in play here,
> analogous to the rule about pointing out a spelling correction.
> (yes, I can't resit either.)
>

unless the eternal sitter stands up....
-- 
Philoponus

"An actual infinite cannot exist."
"An infinite temporal regress of events is an actual infinite."
"Thus an infinite temporal regress of events cannot exist."

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

#101808 — Re: comparison logic

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
>> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
>> resit nit-picking.)
>
> I think there is a second-order nit-picking rule in play here,
> analogous to the rule about pointing out a spelling correction.
> (yes, I can't resit either.)

What is a "variable"?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#101846 — Re: comparison logic

On 14/01/17 21:56, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>>> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
>>> resit nit-picking.)
>>
>> I think there is a second-order nit-picking rule in play here,
>> analogous to the rule about pointing out a spelling correction.
>> (yes, I can't resit either.)
>
> What is a "variable"?

IIRC, a variable doesn't, a constant isn't, and a function won't.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#101914 — Re: comparison logic

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> [...]
>
>>> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
>>> resit nit-picking.)
>>
>> I think there is a second-order nit-picking rule in play here,
>> analogous to the rule about pointing out a spelling correction.
>> (yes, I can't resit either.)
>
> What is a "variable"?

I assume the word "variable" here is supposed to mean a declared
compile-time entity that corresponds to an object at run-time.
Given the context, I don't know what else it could mean.

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

#101918 — Re: comparison logic

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>
>>>> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
>>>> resit nit-picking.)
>>>
>>> I think there is a second-order nit-picking rule in play here,
>>> analogous to the rule about pointing out a spelling correction.
>>> (yes, I can't resit either.)
>>
>> What is a "variable"?
>
> I assume the word "variable" here is supposed to mean a declared
> compile-time entity that corresponds to an object at run-time.
> Given the context, I don't know what else it could mean.

Of course.  The context was silly nitpicking, and the standard doesn't
use the word "variable" in that sense.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#102746 — Re: comparison logic

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>> [...]
>>>
>>>>> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
>>>>> resit nit-picking.)
>>>>
>>>> I think there is a second-order nit-picking rule in play here,
>>>> analogous to the rule about pointing out a spelling correction.
>>>> (yes, I can't resit either.)
>>>
>>> What is a "variable"?
>>
>> I assume the word "variable" here is supposed to mean a declared
>> compile-time entity that corresponds to an object at run-time.
>> Given the context, I don't know what else it could mean.
>
> Of course.  The context was silly nitpicking, and the standard doesn't
> use the word "variable" in that sense.

It doesn't, but I don't understand why you think of your
statement as nitpicking, since the original context doesn't
represent "variable" as being used in any sense other than the
regular English usage.  Or maybe you thought of it as a silly
nitpick?  The earlier comments were a bit silly, but I didn't
think either of their nitpicks were silly, just nitpicks.

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

#102786 — Re: comparison logic

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>> [...]
>>>>
>>>>>> Provided 'i' is not a volatile-qualified int variable!  (Sorry, I can't
>>>>>> resit nit-picking.)
>>>>>
>>>>> I think there is a second-order nit-picking rule in play here,
>>>>> analogous to the rule about pointing out a spelling correction.
>>>>> (yes, I can't resit either.)
>>>>
>>>> What is a "variable"?
>>>
>>> I assume the word "variable" here is supposed to mean a declared
>>> compile-time entity that corresponds to an object at run-time.
>>> Given the context, I don't know what else it could mean.
>>
>> Of course.  The context was silly nitpicking, and the standard doesn't
>> use the word "variable" in that sense.
>
> It doesn't, but I don't understand why you think of your
> statement as nitpicking, since the original context doesn't
> represent "variable" as being used in any sense other than the
> regular English usage.  Or maybe you thought of it as a silly
> nitpick?  The earlier comments were a bit silly, but I didn't
> think either of their nitpicks were silly, just nitpicks.

I'm not entirely sure what the "regular English usage" of the word
"variable" is at it applies to C.  In Ben's nitpick, "object"
would have been more accurate than "variable".  For example, it
would apply to a const-qualified object, which isn't something
I'd refer to as a "variable".  (There are also questions about
whether a struct member or an array element is a "variable", but
those don't apply assuming `i` is meant to be taken literally as
a single identifier, and presumably not a macro.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#103103 — Re: comparison logic

Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Provided 'i' is not a volatile-qualified int variable!
>>>>>>> (Sorry, I can't resit nit-picking.)
>>>>>>
>>>>>> I think there is a second-order nit-picking rule in play here,
>>>>>> analogous to the rule about pointing out a spelling correction.
>>>>>> (yes, I can't resit either.)
>>>>>
>>>>> What is a "variable"?
>>>>
>>>> I assume the word "variable" here is supposed to mean a declared
>>>> compile-time entity that corresponds to an object at run-time.
>>>> Given the context, I don't know what else it could mean.
>>>
>>> Of course.  The context was silly nitpicking, and the standard
>>> doesn't use the word "variable" in that sense.
>>
>> It doesn't, but I don't understand why you think of your
>> statement as nitpicking, since the original context doesn't
>> represent "variable" as being used in any sense other than the
>> regular English usage.  Or maybe you thought of it as a silly
>> nitpick?  The earlier comments were a bit silly, but I didn't
>> think either of their nitpicks were silly, just nitpicks.
>
> I'm not entirely sure what the "regular English usage" of the word
> "variable" is at it applies to C.

I mean in the sense of a definition that might be found in a
regular dictionary of English, as opposed to some specialized
technical dictionary or a technical requirements document like
the ISO C standard.

> In Ben's nitpick, "object"
> would have been more accurate than "variable".

I don't agree with this assessment.  The original remark looks
like it is making a statement about an identifier 'i'.  An
identifier is not an object.  An identifier may be associated
with an object, but it is not itself an object.  Text in the
Standard is sloppy about this distinction but that doesn't mean
we have to be.  The word "variable", however, is perfectly apt
for making a statement about an identifier, as opposed to the
memory area set aside at run time to hold the value.  In this
context the word "variable" is a better fit than the word
"object" for what it is that is being talked about.  (Note also
that the word "variable" is what was used in the posting Ben was
responding to.)

> For example, it
> would apply to a const-qualified object, which isn't something
> I'd refer to as a "variable".

Whether you would say so or not, such usage is in common parlance
and widely understood.  What is in the Standard doesn't change the
meaning of ordinary English, even if the meanings in question
apply only in technical dialect.

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web