comp.lang.c - 5 new messages in 3 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Shorter Rot13 Pure-C Implementation - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/01d6c3202b93f929?hl=en
* C from Fortran Calls - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/ec59d7fd61d468f8?hl=en
* Test for function existence? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/5e44bad5942760a6?hl=en

==============================================================================
TOPIC: Shorter Rot13 Pure-C Implementation
http://groups.google.com/group/comp.lang.c/t/01d6c3202b93f929?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 6 2010 7:34 pm
From: Agent Spikes

I just improved upon the 64-byte implementation of Rot13 as listed
here and got it down 2 more characters:

http://hea-www.harvard.edu/~fine/Tech/rot13.html

The updated line is:
main(a){while(a=getchar())putchar(a-1/((a&~32)/13*2-11)*13);}

The improvements were achieved by:
- Get the NOT off of the getchar() and adjust throughout the equation
[1 byte]
- Apply De Morgan's laws newly created "~(~a|32)", leaving us with "(a|
~32)" [1 byte]

Feel free to rip it apart and let me know what you think. :)

== 2 of 2 ==
Date: Sat, Mar 6 2010 7:45 pm
From: Agent Spikes

Quick summary of changes correction:

"(a|~32)" is actually ""(a&~32)"

I'm only human after all :)

On Mar 6, 7:34 pm, Agent Spikes <wesley.spi...@gmail.com> wrote:
> - Apply De Morgan's laws newly created "~(~a|32)", leaving us with "(a|
> ~32)" [1 byte]

==============================================================================
TOPIC: C from Fortran Calls
http://groups.google.com/group/comp.lang.c/t/ec59d7fd61d468f8?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 6 2010 7:38 pm
From: Keith Thompson

Phred Phungus <Phred@example.invalid> writes:
> Keith Thompson wrote:
> snip
>> I don't know FORTRAN very well, but there's a problem in your C code.
>> In create_shp_(), ``a'' is a pointer to int. You print it with a
>> "%d" format, which requires an int, not a pointer. Garbage is to be
>> expected; actually the behavior is undefined. The value -1074936500
>> (0xbfedc54c with 2's-complement wraparound) seems plausible as a
>> 32-bit address value -- or it might just be garbage.
>
> I recognize that number. How do you get to thinking of it as a
> plausible address value?

Nothing more than a hunch. How do you recognize it?

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

== 2 of 2 ==
Date: Sat, Mar 6 2010 8:44 pm
From: Phred Phungus

Keith Thompson wrote:
> Phred Phungus <Phred@example.invalid> writes:
>> Keith Thompson wrote:
>> snip
>>> I don't know FORTRAN very well, but there's a problem in your C code.
>>> In create_shp_(), ``a'' is a pointer to int. You print it with a
>>> "%d" format, which requires an int, not a pointer. Garbage is to be
>>> expected; actually the behavior is undefined. The value -1074936500
>>> (0xbfedc54c with 2's-complement wraparound) seems plausible as a
>>> 32-bit address value -- or it might just be garbage.
>> I recognize that number. How do you get to thinking of it as a
>> plausible address value?
>
> Nothing more than a hunch. How do you recognize it?
>

As one of my persistent errors. :(

--
fred

==============================================================================
TOPIC: Test for function existence?
http://groups.google.com/group/comp.lang.c/t/5e44bad5942760a6?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 6 2010 11:39 pm
From: gordonb.7z52w@burditt.org (Gordon Burditt)

>Is there a standard, or at least common, method for testing for the
>existence of a function in a particular compiler implementation that
>does not depend upon the definition of an associated preprocessor
>variable?

Unless you count autoconf and similar systems, no.

>For instance chown() is often not implemented on some
>platforms, so what I'm looking for is an expression like:

Is chown() supplied by the OS or the compiler? It is *not* supposed
to be declared in Standard C header files and it's supposed to be
allowed to write your own.

>#if MAGIC_HERE(chown)
> /* use chown() somehow */
>#else
> /* do nothing */
>