twitter: comp.lang.c - 24 new messages in 9 topics

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: how to know local port used in an udp client ?
http://groups.google.com/group/comp.lang.c/t/8735d94d5c065a4b?hl=en
==============================================================================

== 1 of 8 ==
Date: Sat, Dec 12 2009 9:36 am
From: Antoninus Twink

On 12 Dec 2009 at 8:12, Greg2fs wrote:
> Hello, I know the port used by my udp client to forward it using upnp.
> How to do ?

Use getsockname(2).

Or, choose which port to bind to yourself instead of letting the socket
layer choose an available ephemeral port.

Please ignore the trolls who seek to disrupt this newsgroup by
restricting discussion of valid C programming topics like networking.

== 2 of 8 ==
Date: Sat, Dec 12 2009 9:42 am
From: Antoninus Twink

On 12 Dec 2009 at 17:36, Richard wrote:
> This group is about all C related programming as defined in its
> founding charter.

Exactly.

It is interesting that none of the topicality taliban have the courage
of their convictions to set up comp.lang.iso-c or comp.lang.c.iso and
see just how popular a group restricted to ISO C would be...

== 3 of 8 ==
Date: Sat, Dec 12 2009 10:06 am
From: Richard

Antoninus Twink <nospam@nospam.invalid> writes:

> On 12 Dec 2009 at 17:36, Richard wrote:
>> This group is about all C related programming as defined in its
>> founding charter.
>
> Exactly.
>
> It is interesting that none of the topicality taliban have the courage
> of their convictions to set up comp.lang.iso-c or comp.lang.c.iso and
> see just how popular a group restricted to ISO C would be...
>

Indeed.

I often wonder why I am unable to see "ISO" in the group's name. It must
be there. Surely.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

== 4 of 8 ==
Date: Sat, Dec 12 2009 10:32 am
From: Seebs

On 2009-12-12, Greg2fs <greg2fs@gmail.com> wrote:
> Isn't it a c group ? I don't understand...

The C language doesn't have sockets. Some specific implementations have
sockets, but the way you use sockets varies widely from one system to another,
so there's no generic answer. If you're on a Unix-derived system, you can
probably get good answers in comp.unix.programmer, but those same answers will
be worthless to you if you're on Windows...

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 5 of 8 ==
Date: Sat, Dec 12 2009 10:43 am
From: Antoninus Twink

On 12 Dec 2009 at 18:32, Seebs wrote:
> The C language doesn't have sockets.

Nonsense.

Are you trying to argue that

int socket(int domain, int type, int protocol);

is not a C API? If so, I call bullshit.

My advice would be to leave that sort of stupidity to Heathfield and
Thomson.

> If you're on a Unix-derived system, you can probably get good answers
> in comp.unix.programmer, but those same answers will be worthless to
> you if you're on Windows...

This is nonsense. Sockets are very portable - Windows also uses
Berkeley sockets.

This is a great example of something that is indisputably better
discussed in a more general group like clc, because it *isn't* specific
to Windows or to *nix.

== 6 of 8 ==
Date: Sat, Dec 12 2009 10:47 am
From: Kaz Kylheku

On 2009-12-12, Antoninus Twink <nospam@nospam.invalid> wrote:
> On 12 Dec 2009 at 8:12, Greg2fs wrote:
>> Hello, I know the port used by my udp client to forward it using upnp.
>> How to do ?
>
> Use getsockname(2).

Note that getsockname may return zero for an empehemeral socket.
It's not a portable way of finding the actual port obtained.

> Or, choose which port to bind to yourself instead of letting the socket
> layer choose an available ephemeral port.

It's best to implement you write your own loop to scan the port space
for an available port, if you want a de-facto ephemeral port /and/ know
what it is in a portable way rather than relying on getsockname.
Moreover, you can control the allocation range this way, which you must
do if your client is to have any hope of getting out through some
firewalls.

== 7 of 8 ==
Date: Sat, Dec 12 2009 10:47 am
From: Richard

Antoninus Twink <nospam@nospam.invalid> writes:

> On 12 Dec 2009 at 18:32, Seebs wrote:
>> The C language doesn't have sockets.
>
> Nonsense.
>
> Are you trying to argue that
>
> int socket(int domain, int type, int protocol);
>
> is not a C API? If so, I call bullshit.
>
> My advice would be to leave that sort of stupidity to Heathfield and
> Thomson.
>
>> If you're on a Unix-derived system, you can probably get good answers
>> in comp.unix.programmer, but those same answers will be worthless to
>> you if you're on Windows...
>
> This is nonsense. Sockets are very portable - Windows also uses
> Berkeley sockets.
>
> This is a great example of something that is indisputably better
> discussed in a more general group like clc, because it *isn't* specific
> to Windows or to *nix.
>

Is this Seebs guy a Heathfield sock? He has all the mannerisms and
annoying starchiness.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

== 8 of 8 ==
Date: Sat, Dec 12 2009 10:50 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <slrnhi7p31.gee.nospam@nospam.invalid>,
Antoninus Twink <nospam@nospam.invalid> wrote:
>On 12 Dec 2009 at 18:32, Seebs wrote:
>> The C language doesn't have sockets.
>
>Nonsense.
>
>Are you trying to argue that
>
>int socket(int domain, int type, int protocol);
>
>is not a C API? If so, I call bullshit.
>
>My advice would be to leave that sort of stupidity to Heathfield and
>Thomson.

To be fair, their position *is* consistent and logical, given their
definition(s). It's just that their definition(s) is/are ludicrous.

==============================================================================
TOPIC: biew-6.1.0 has been released
http://groups.google.com/group/comp.lang.c/t/076b045cf70c99fb?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 12 2009 9:38 am
From: Nickols_K

BIEW- is multiplatform portable viewer of binary files with built-in
editor in binary, hexadecimal and disassembler modes. It uses native
Intel syntax for disassemble. Highlight AVR/Java/Athlon64/Pentium 4/
K7-
Athlon disassembler, russian codepages convertor, full preview of
formats - MZ, NE, PE, NLM, coff32, elf partial - a.out, LE, LX,
PharLap; code navigator and more over.

Details: http://biew.sourceforge.net

==============================================================================
TOPIC: Advanced data structures
http://groups.google.com/group/comp.lang.c/t/2edd7d58412b2f69?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Dec 12 2009 9:39 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> igcd a 0 = a
> igcd a b = igcd b (a `rem` b)
>
> int igcd(int a, int b)
> {
> return b ? igcd(b, a % b) : a;
> }

>Most people are happy to say that they embody some common thing -- a
>recursive GCD algorithm -- despite the huge differences in form and,
>indeed, semantics. Do you not bother to name or talk about this
>commonality?

I agree that they share something. It is the exploitation of
the same mathematical theorem.

I just do not like the idea of this theorem being useful to
calculate the GCD in each and every programming language,
because, for example:

- when the language already does have a GCD, it is not
required, and

- when the language does not have a primitive remainder
operation, there might be better means to perform
the calculation (possibly exploiting other mathematical
theorems).

== 2 of 6 ==
Date: Sat, Dec 12 2009 9:47 am
From: Ben Bacarisse

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> igcd a 0 = a
>> igcd a b = igcd b (a `rem` b)
>>
>> int igcd(int a, int b)
>> {
>> return b ? igcd(b, a % b) : a;
>> }
>
>>Most people are happy to say that they embody some common thing -- a
>>recursive GCD algorithm -- despite the huge differences in form and,
>>indeed, semantics. Do you not bother to name or talk about this
>>commonality?
>
> I agree that they share something. It is the exploitation of
> the same mathematical theorem.

That's fair enough, but I won't be using your terminology any time
soon and I think you'll have to accept that most people call this
commonality "an algorithm" not "the exploitation of a mathematical
theorem".

> I just do not like the idea of this theorem being useful to
> calculate the GCD in each and every programming language,
> because, for example:

Yes, but I don't think anyone said that. If you have recursion and a
mod operation in language X, the above "algorithm" can be represented
in X. No one has said it is good to so or the best way to calculate
GCD or any such thing.

> - when the language already does have a GCD, it is not
> required, and
>
> - when the language does not have a primitive remainder
> operation, there might be better means to perform
> the calculation (possibly exploiting other mathematical
> theorems).

--
Ben.

== 3 of 6 ==
Date: Sat, Dec 12 2009 9:58 am
From: cri@tiac.net (Richard Harter)

On 12 Dec 2009 16:23:35 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>I have another definition of »algorithm«: An algorithm is
>>>the implementation of some feature using the means of a
>>>specific target language. [...]
>>one "algorithm" for finding the GCD of two numbers in C,
>>another for C++, another for Basic, another for Java, ...
>
> The GCD requires the mod operation. So, when a language
> does not have a mod operation, an implementation of the
> mod operation becomes part of the implementation of the
> GCD, otherwise it don't.

There is a distinction that you are blurring over - the
distinction between an algorithm and the implementation of an
algorithm. Algorithms are ordinarily understood to be a
description of a suite of steps that can be taken to achieve some
specified results. The key point is that the algorithm specifies
what the steps must do rather than how they do what they must do.

As a matter of convenience programming languages are commonly
used to describe algorithms. Unfortunately most programming
languages express "how to do something" but not "what is to be
done". As a result, algorithms are often specified in terms of
an implementation. This is a regular source of confusion - it
becomes easy to confuse algorithms and their implementations.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.

== 4 of 6 ==
Date: Sat, Dec 12 2009 10:14 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

cri@tiac.net (Richard Harter) writes:
>The key point is that the algorithm specifies
>what the steps must do rather than how they do what they must do.

The wording �steps� seems to be adequate for imperative
languages. In functional or logical languages, there are no
�sequences of steps�. Insofar, I agree, that, yes, you can
define �algorithm� that way, but it seems tailored somewhat
towards imperative languages.

== 5 of 6 ==
Date: Sat, Dec 12 2009 10:28 am
From: Seebs

On 2009-12-12, jacob navia <jacob@spamsink.net> wrote:
> In ruby, you have built-in hash tables, sets, and many other containers.
> You have to use the implementation that the language offers. Obviously
> you *could* write your own, but all performance considerations would
> be difficult to measure in an interpreter.

Yeah. On the other hand, there's usually not much REASON to use other
implementations.

> This is surely not really obvious for people not speaking ruby
> fluently...

Not especially, no.

> But exactly THAT makes you AWARE of that overhead, that is an inherent
> part of the algorithm's cost!

Yes. I use Ruby for things where I'm pretty sure modern computers are
Fast Enough. Then I'm pretty much okay with ignoring the overhead in most
cases, and for most of what I write, the cost of the time it would take me
to implement it in a less expressive language far exceeds the cost of the
computer Ruby will need to get it done faster anyway. :)

> Hiding "details" can be OK, but when designing an algorithm and
> evaluating its cost, those details do matter. In ruby or java
> memory management costs are hidden by the language, and you are
> forced to use the OO paradigm.

Often, the details matter much less than you might expect. I did an
iterative fractal design once, and spent quite a while paying attention
to those low-level details, finally managing to get about a 40% increase.
Then I eliminated the 0-length lines from the end of one segment to the
beginning of the next, and by about depth 5-6, I had eliminated more
than half of the points drawn, yielding a >50% increase, and >1000% for
the levels of depth where that pushed the data set outside what you could
keep in memory at a time...

== 6 of 6 ==
Date: Sat, Dec 12 2009 10:39 am
From: "Malcolm McLean"

"Seebs" <usenet-nospam@seebs.net> wrote in message
>
> C is pretty expressive, but a lot of things end up with a bunch of
> overhead that isn't actually the implementation of the algorithm, but
> rather, the bookkeeping to allow that implementation to work.
>
The problem is that it leads to a dichotomy between "teaching" and
"industrial" code. I chose C for Basic Algorithms, but it meant that some of
the fucntions would fail on extreme inputs. The only way round is to add
lots of error-checking and memory management code, which would distract from
the algorithm.

However the publishers didn't like the fact that it was in C.

==============================================================================
TOPIC: question on passing char ** to fn
http://groups.google.com/group/comp.lang.c/t/dc67a6d728d09b10?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 12 2009 10:28 am
From: "Malcolm McLean"

"Eric" <apophis@ruler.of.the.night.org> wrote in message
> char list[6][32];
>
> void fn(char **a_list)
> How do i do this correctly?
>
Multi-dimensional arrays in C are implemented very poorly. They work as
expected as long as the array is in scope, but as soon as you try to pass to
a subroutine, you find ypurself immeshed in difficulties and stupid syntax.

The reason for the problem is that a multi-dimensional array is just a
contiguous area of memeory. It carries no size information with it. So a
subroutine doesn't know the x-dimension of the array, unless you tell it. If
you tell it, you can only pass arrays with an xdimension of precisely the
number ypu specify, which makes subroutines useless for most purposes.

You can semi-solve the problem by creating a multidimensional array which
consists of a list of pointers (eg a char **). However you then can't use
"flat" multi-dimensional arrays, and arrays of pointers are a nuisance to
intialise.

Most experienced C programmers simply use flat arrays and do the
calculations by hand (index = y * width + x). This isn't ideal, but it
works, and gets round the syntax and interfacing problems.

==============================================================================
TOPIC: Initializing a list
http://groups.google.com/group/comp.lang.c/t/e66383e9c73c4109?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Dec 12 2009 10:31 am
From: "Malcolm McLean"

"Tagore" <c.lang.myself@gmail.com> wrote in message
>
> const int arr_List[]={34,12,67,34};
>
> but t I have to also declare its size explicitly.
> const int size=4;
>
> Now problem is that every-time I run my program with new contents in
> arr_List, I have to also change value of size..
> Is there any other way for it?
>
char *list = "34, 12, 67, 34";

int *l = makelist(list, &N);

int *makelist(const char *initialisers, int *N)
{
/* a bit of logic here to call malloc(), and atoi() to convert your list
*/
}

it's a bit of a round about way of doing it, but if it's a nuisance to keep
updating a lot of lists each time, it might be worth the effort.

== 2 of 2 ==
Date: Sat, Dec 12 2009 10:32 am
From: "Malcolm McLean"

"Ian Collins" <ian-news@hotmail.com> wrote in message
> Keith Thompson wrote:
>> Tagore <c.lang.myself@gmail.com> writes:
>>> If I want to initialize a list of numbers to be used in a program.
>>> like
>>>
>>> const int arr_List[]={34,12,67,34};
>>>
>>> but t I have to also declare its size explicitly.
>>> const int size=4;
>>>
>>> Now problem is that every-time I run my program with new contents in
>>> arr_List, I have to also change value of size..
>>> Is there any other way for it?
>>
>> const int size = sizeof arr_List / sizeof arr_List[0];
>>
>> You might want to wrap this in a macro:
>>
>> #define ARRAY_SIZE(arr) (sizeof (arr) / sizeof (arr)[0])
>> ....
>> const int size = ARRAY_SIZE(arr_List);
>
> <pedantry>
> These should be const size_t
> </pedantry>
>
See the evil.

==============================================================================
TOPIC: What is the gain of "inline"
http://groups.google.com/group/comp.lang.c/t/a31a1e510e2943b2?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Dec 12 2009 10:33 am
From: raltbos@xs4all.nl (Richard Bos)

Kaz Kylheku <kkylheku@gmail.com> wrote:

> On 2009-12-11, Dik T. Winter <Dik.Winter@cwi.nl> wrote:

> > Consider 'max' with two integers.
>
> In C, you're best off with the macro.

> You can do max ``right'' with C++ template classes, functions and
> partial specialization.

Feel free to piss off to comp.lang.c++.

Richard

== 2 of 3 ==
Date: Sat, Dec 12 2009 10:33 am
From: raltbos@xs4all.nl (Richard Bos)

jacob navia <jacob@nospam.org> wrote:

> Tom St Denis a écrit :
> > On Dec 9, 3:11 pm, Ben Pfaff <b...@cs.stanford.edu> wrote:
> >> One additional effect of "inline" with the compiler that I use is
> >> to suppress warnings about a function that is defined but never
> >> used. This is presumably because "static inline" functions are
> >> often defined in header files and thus may not be used by every
> >> translation unit that includes them, whereas it is usually an
> >> oversight if an ordinary "static" function is never called.

> > Code doesn't go in header files.
> >
> > That is all.

Tom, you're an idiot.

> Inline functions MUST be written in header files...

jacob, you're an idiot.

Two idiots disagreeing 100% with one another doesn't make either of them
any jot less an idiot.

Richard

== 3 of 3 ==
Date: Sat, Dec 12 2009 10:33 am
From: raltbos@xs4all.nl (Richard Bos)

Willem <willem@stack.nl> wrote:

> Your arguments apply equally to macro's,

I know why you spelled it that way, but in English it's spelt without
the apostrophe.

Yes, I used to get this wrong, too. Probably still do, on occasion.

Richard

==============================================================================
TOPIC: Pointer and string literal question
http://groups.google.com/group/comp.lang.c/t/23a9dca12b4bed2b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 12 2009 10:33 am
From: raltbos@xs4all.nl (Richard Bos)

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

> Kaz Kylheku <kkylheku@gmail.com> writes:
> > On 2009-12-10, Jens Thoms Toerring <jt@toerring.de> wrote:
> >> Tagore <c.lang.myself@gmail.com> wrote:
> >>> char *s="LET";
> >>> char *t="LET";
> [...]
> >> Why do you think so? It's correct that both 's' and 't' point to
> >> string literals - but since the strings they point to are identical
> >> it's one of the most simple (memory-related) optimizations for the
> >> compiler to make them point to the same location. Actually, that's
> >> the very reason why you aren't allowed to change string literals -
> >> i.e. if you would do e.g.
> >
> > It's not the only reason.
> >
> > Literals are effectively pieces of the program text made available
> > to itself as data, so that modifying a literal de facto constitutes
> > self-modifying code. Self-modifying code can't be placed into
> > read-only storage, such as a ROM, or write-protected virtual pages.
> >
> >> s[1] = 'x'; /* not allowed by the C standard! */
> >
> > This undefinedness also means that once you perform s[1] = 'x', a subsequent
> > statement of the form
> >
> > if (s[1] == 'x') ...
> >
> > could go either way (if it ever gets to execute at all). It's not just about
> > other copies of the i literal being affected by the change.
> >
> > The translated program is also simply not required to be aware of
> > self-modifications like this.
> >
> > Not only can another instance of the literal share the same space as
> > s, but the expression s[1] can be optimized to a constant which does
> > not respond to changes to s.
>
> Agreed.
>
> In addition, it's also likely (but not required) that attempting:
>
> s[1] = 'x';
>
> will cause your program to crash. (In fact, this is the *best*
> outcome, since it shows you where the error is.)

It's even possible that a later

if (ch == 'L')

is compiled to compare to the first character of your string literal,
instead of to a literal 'L', on systems where this is faster. It is even
allowed that, if you do try to change the string, that comparison fails
when ch is 'L', at a point which _appears_ to have nothing whatsoever to
do with the original string literal.
I have never seen an implementation which goes that far in its
optimisations (in fact, I've never seen one where it would make sense),
but I would not be very surprised to find one. It would certainly be
perfectly legal.

Richard

==============================================================================
TOPIC: dice generator problems
http://groups.google.com/group/comp.lang.c/t/f7251123f2e50284?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 12 2009 10:33 am
From: raltbos@xs4all.nl (Richard Bos)

gazelle@shell.xmission.com (Kenny McCormack) wrote:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >Unlikely to be what Seebs is talking about, but icon has this pattern
> >though not the exact syntax quoted. In icon you can say
> >
> > i == (1 | 2)
> >
> >to ask is i is 1 or 2 (the parentheses are needed). You can even say:
> >
> > (x | y | z) == (1 | 2)
> >
> >to find out is any of x, y or z are either 1 or 2.
>
> Many languages (though not low-level ones like C) had an "in" operator.
> For example, SQL:
>
> WHERE fld in (a,b,c)

Yah. But unlike those languages, Icon does actual, backtracking,
pattern-matching.

Yes, this is beautiful.

Yes, this is horrendous.

Richard

==============================================================================
TOPIC: The Six Periods of the Creation
http://groups.google.com/group/comp.lang.c/t/7e344a8fd63e3ffb?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 12 2009 10:35 am
From: Sjouke Burry

love my god wrote:
> The Six Periods of the Creation

Period 1:Crazy spammer assisting God.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Saturday, December 12, 2009

comp.lang.c - 24 new messages in 9 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts