comp.lang.c - 23 new messages in 8 topics - digest

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

comp.lang.c@googlegroups.com

Today's topics:

* Best way/library to draw individual pixels on screen? (for fractals) - 8
messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
* Reverse and Alphabetize in under 2kb - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/11babfbf4fe82c07?hl=en
* Is there a better way to achieve this ? - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/dd4de60290d2834a?hl=en
* Call For Manuscripts: International Journal of Signal Processing (IJSP) - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/5893df3c622249a3?hl=en
* fixing compile warnings - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/41e53e9bb82de6ec?hl=en
* problem 1.13 The C programming language - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/e3b5a2688181479c?hl=en
* Free Computer Hacking Tips - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/bcf05b1319ec44a4?hl=en
* decoding a declaration - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/259df4a3d0342511?hl=en

==============================================================================
TOPIC: Best way/library to draw individual pixels on screen? (for fractals)
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Mar 3 2010 3:06 pm
From: Wolfnoliir

Wolfnoliir a écrit :
> Malcolm McLean a écrit :
>> On Mar 3, 2:00 am, Wolfnoliir <wolfnol...@gmail.com> wrote:
>>> Hello,
>>> I would like to know what library and method you would recommend for
>>> displaying individual pixels on the screen
>>>
>>> I have some knowledge of SDL and OpenGL already.
>>>
>> Write into an off-screen buffer using rgb / palette inddex values.
>> Then use openGL to transfer the buffer to screen in a signle call.
>> Unfortunatetly the openGL documentation site is so sophisticated that
>> it keeps crashing my browser, so I couldn't look up the call for you.
>> The technical term is "blit".
>>
>>
> This looks like what I am looking for. I'll go look it up. Thank you.
I found glDrawPixels() which seems to work fine.:)

== 2 of 8 ==
Date: Wed, Mar 3 2010 2:25 pm
From: Wolfgang Draxinger

Wolfnoliir wrote:

>> This looks like what I am looking for. I'll go look it up. Thank you.
> I found glDrawPixels() which seems to work fine.:)

glDrawPixels is to be considered deprecated, if it's used in conjunction
with rendering other primitives - for just displaying a single image
convering the whole window it's okay, but make sure to use an internal
format, that requires no conversion. Most often this is GL_BGR.

The recommended way to draw pixel images using OpenGL is to first transfer
them into a texture, then render this using a quad. The reasoning behind
this is, that glDrawPixels forces synchronization of the rendering pipeline
thus stalling the rasterizer. Going the way over a pixel buffer object and a
texture allows for asynchronous processing.

Getting texels perfectly screen pixel aligned requires some thinking if
using a "normal" texture. I explained it here http://tinyurl.com/cgndc8

Using a GL_TEXTURE_RECTANGLE instead of GL_TEXTURE_2D it's straightforward.

Wolfgang

== 3 of 8 ==
Date: Wed, Mar 3 2010 2:44 pm
From: "bartc"

"Wolfnoliir" <wolfnoliir@gmail.com> wrote in message
news:4b8eddf5$0$9501$426a74cc@news.free.fr...

> I found glDrawPixels() which seems to work fine.:)

("Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message
news:1486165.hTKx8HoL2I@narfi.yggdrasil.draxit.de...

> glDrawPixels is to be considered deprecated, if it's used in
> conjunction... )

If it's any help at this stage, there is also an OpenGL discussion group
comp.graphics.api.opengl

(Although, OpenGL is more for rendering, I wouldn't use it myself for basic
pixel graphics. (I use my own library which makes use of Win32/GDI, but
then I'm only interested in one platform.))

--
bartc

== 4 of 8 ==
Date: Wed, Mar 3 2010 3:29 pm
From: Squeamizh

On Mar 3, 6:12 am, Andrew Poelstra <apoels...@localhost.localdomain>
wrote:
> On 2010-03-03, Ersek, Laszlo <la...@ludens.elte.hu> wrote:
>
> > In article <4b8dedf3$0$24604$426a7...@news.free.fr>, Wolfnoliir <wolfnol...@gmail.com> writes:
>
> >> I also have the impression that some may have misunderstood me: I am not
> >> talking about putting pixels on the screen directly but in a window
> >> actually. I am sorry that my first message was unclear.
>
> > I think one of the standard answers is Qt.
>
> >http://qt.nokia.com/
>
> > Cheers,
> > lacos
>
> Qt is a quagmire of inconsistencies, undocumented bugs and missing
> functionality. And it forces you to use C++, which has all those
> problems on its own.

C++ does not have all those problems on its own. I'm not sure why you
would say that.

>
> If the OP doesn't want to save to disk, he should see if he can
> save a PPM file to memory - which will be nonportable but likely
> pretty simple on each platform that he ports to. (Or impossible,
> in which case he can save to disk).
>
> Failing that, perhaps a Gdk pixbuf would be portable enough.

== 5 of 8 ==
Date: Wed, Mar 3 2010 3:34 pm
From: Branimir Maksimovic

On Wed, 3 Mar 2010 15:29:44 -0800 (PST)
Squeamizh <squeamz@hotmail.com> wrote:

> On Mar 3, 6:12 am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
> >
> > Qt is a quagmire of inconsistencies, undocumented bugs and missing
> > functionality. And it forces you to use C++, which has all those
> > problems on its own.
>
> C++ does not have all those problems on its own. I'm not sure why you
> would say that.

It's a flame bait ;)

Greets

--
http://maxa.homedns.org/

Sometimes online sometimes not

== 6 of 8 ==
Date: Wed, Mar 3 2010 3:49 pm
From: Andrew Poelstra

On 2010-03-03, Squeamizh <squeamz@hotmail.com> wrote:
> On Mar 3, 6:12 am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> Qt is a quagmire of inconsistencies, undocumented bugs and missing
>> functionality. And it forces you to use C++, which has all those
>> problems on its own.
>
> C++ does not have all those problems on its own. I'm not sure why you
> would say that.
>

It does, though. Perhaps I worded that too strongly (it does
look like a flame bait, even to me, though I assure you this
was not my intent.)

See http://www.yosefk.com/c++fqa

for a critique from somebody quite passionate about this issue.

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 7 of 8 ==
Date: Wed, Mar 3 2010 7:50 pm
From: Wolfnoliir

Wolfgang Draxinger a écrit :
> Wolfnoliir wrote:
>
>>> This looks like what I am looking for. I'll go look it up. Thank you.
>> I found glDrawPixels() which seems to work fine.:)
>
> glDrawPixels is to be considered deprecated, if it's used in conjunction
> with rendering other primitives - for just displaying a single image
> convering the whole window it's okay, but make sure to use an internal
> format, that requires no conversion. Most often this is GL_BGR.
>
> The recommended way to draw pixel images using OpenGL is to first transfer
> them into a texture, then render this using a quad. The reasoning behind
> this is, that glDrawPixels forces synchronization of the rendering pipeline
> thus stalling the rasterizer. Going the way over a pixel buffer object and a
> texture allows for asynchronous processing.
>
> Getting texels perfectly screen pixel aligned requires some thinking if
> using a "normal" texture. I explained it here http://tinyurl.com/cgndc8
>
> Using a GL_TEXTURE_RECTANGLE instead of GL_TEXTURE_2D it's straightforward.
>
>
> Wolfgang
>
Thanks. I will look this up when I have time. (for the time being
glDrawPixels() is working well)

I am using GL_RGB format because it seems more natural. Should I try
GL_BGR instead? What difference would it make?
I am also using GL_FLOAT. Would I gain performance by changing it to
GL_UNSIGNED_BYTE?

== 8 of 8 ==
Date: Wed, Mar 3 2010 8:03 pm
From: Peter Nilsson

Wolfnoliir <wolfnol...@gmail.com> wrote:
> Wolfgang Draxinger a écrit :
<snip>
> Thanks. I will look this up when I have time. (for the
> time being glDrawPixels() is working well)
>
> I am using GL_RGB format because it seems more natural.
> Should I try GL_BGR instead? What difference would it
> make? I am also using GL_FLOAT. Would I gain performance
> by changing it to GL_UNSIGNED_BYTE?

Why not ask in a group that deals with open gl? Sure, it
saves you time, but it only increases the off topic noise
in clc and decreases your chance of getting quality peer
reviewed responses.

--
Peter

==============================================================================
TOPIC: Reverse and Alphabetize in under 2kb
http://groups.google.com/group/comp.lang.c/t/11babfbf4fe82c07?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 3 2010 3:14 pm
From: Willem

Keith Thompson wrote:
) Willem <willem@snail.stack.nl> writes:
)> - Yes
)> - A word is anyting that is not a ' ' character
)
) I'm sure you didn't mean to say that "abc" is three words. One
) reasonable definition is that a word is a maximal non-empty substring
) consisting only of non-whitespace characters, but that needs to be
) clarified.

That's roughly what I meant, yes.

)> - They only need to be printed
)> - Yes, case-insensitive
)
) Hmm, I'm not sure I would have assumed case-insensitivity, but the
) word "alphabetizes" does tend to imply it. But this should
) be clarified.

The example given by the OP also implies case-insensitivity.

)> - Yes you can (works both in ASCII and EBCDIC)
)> - The source code, after whitespace is removed where possible
)
) The stated requirements don't imply to me that whitespace may be
) removed; I would assume it's the full size of the source file.
) (Which argues for using a Unix-like system rather than Windows,
) so each end-of-line is only 1 byte rather than 2.)

Then you could make a 'better' program by removing the whitespace yourself.
Note I said 'where possible', meaning to imply that the result should still
compile and work.

As it turns out, it can be done quite easily in 1Kb, though.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

== 2 of 2 ==
Date: Wed, Mar 3 2010 5:40 pm
From: Peter Nilsson

Willem <wil...@snail.stack.nl> wrote:
<snip>
> As it turns out, it can be done quite easily in 1Kb, though.

Indeed.

% type obfuscate.c
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define q1(q2,q3) (((q3)<(q2))-((q2)<(q3)))
int q4(const void*q5,const void*q6){const char*q7="abcdefgh"
"ijklmnopqrstuvwxyz";const unsigned char*q8=q5;const unsigned
char*r9=q6;unsigned char q10=tolower(*q8);unsigned char q11=
tolower(*r9);const char*q12=strchr(q7,q10);const char*q13=
strchr(q7,q11);if(q12&&q13)return q1(q12-q7,q13-q7);if(q12)
return-1;if(q13)return+1;return q1(q10,q11);}void q14(char*
q15,char*q16){if(!q16)q16=q15+strlen(q15);if(q15!=q16)for(;
q15<--q16;q15++){char q17;q17=*q15;*q15=*q16;*q16=q17;}}int
main(void){static char q18[1024];char*q15,*q16;if(fgets(q18,
sizeof q18,stdin)){char*q19=strchr(q18,'\n');if(q19)*q19=0;
puts(q18);q14(q18,0);for(q15=q18;*q15;q15=q16){q15=q15+strspn
(q15," \t");q16=q15+strcspn(q15," \t");q14(q15,q16);}puts(
q18);for(q15=q18;*q15;q15=q16){q15=q15+strspn(q15," \t");q16
=q15+strcspn(q15," \t");qsort(q15,q16-q15,1,q4);}puts(q18);}
return 0;}

% acc obfuscate.c -o homework.exe

% type input.txt
This is a string

% homework.exe < input.txt
This is a string
string a is This
ginrst a is hisT

% dir obfuscate.c
Volume in drive E is USB DISK
Volume Serial Number is 14CC-F5A9

Directory of E:\C

04/03/2010 12:30 PM 1,000 obfuscate.c
1 File(s) 1,000 bytes
0 Dir(s) 906,080,256 bytes free

%

--
Peter

==============================================================================
TOPIC: Is there a better way to achieve this ?
http://groups.google.com/group/comp.lang.c/t/dd4de60290d2834a?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 3 2010 3:56 pm
From: "Mark"

Francis Moreau wrote:
>> PS. What is the idiom to check sum/subtraction for overflow?
>>
>
> Well when using unsigned type, the following code should work and
> should be portable:
>
> unsigned a, b;
>
> if (a + b < b)
> goto overflow;

So it is guaranteed by the C standard that in case of overfllow the result
of sum will be less then either operand?

> But when using signed type, I can't think of something portable
> anymore.

--
Mark

== 2 of 4 ==
Date: Wed, Mar 3 2010 5:01 pm
From: "christian.bau"

On Mar 3, 11:56 pm, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:

> So it is guaranteed by the C standard that in case of overfllow the result
> of sum will be less then either operand?

Addition of unsigned numbers is well-defined by the C Standard for any
input values; if the mathematical sum of a and b is greater than
UINT_MAX then the result is the mathematical sum (a + b - (UINT_MAX +
1)), which can easily be shown to be less than b in all cases (and
also less than a).

It isn't called "overflow" because the addition will produce the
result as it is defined - the "+" operator for unsigned integers isn't
defined to calculate the sum, but the sum modulo (UINT_MAX + 1) and
that result can always be produced. The "+" operator for signed
integers is defined to produce the mathematical sum. But sometimes it
is impossible to produce that result, and that is called "overflow".

When an overflow happens, nothing is guaranteed. It is undefined
behaviour; anything can happen.

== 3 of 4 ==
Date: Wed, Mar 3 2010 8:24 pm
From: Peter Nilsson

"Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:
> Francis Moreau wrote:
> > > PS. What is the idiom to check sum/subtraction for overflow?

There's no idiom since people don't do it that often.

But observe the maths...

INT_MIN <= a + b <= INT_MAX
<=> INT_MIN - b <= a <= INT_MAX - b

So, for signed integers...

/* summation overflow */
if (b < 0) { if (a < INT_MIN - b) overflow(); }
else { if (INT_MAX - b < a) overflow(); }

/* subraction overflow */
if (b < 0) { if (INT_MAX + b < a) overflow(); }
else { if (a < INT_MIN + b) overflow(); }

> > Well when using unsigned type, the following code should
> > work and should be portable:
> >
> >    unsigned a, b;
> >
> >    if (a + b < b)
> >        goto overflow;
>
> So it is guaranteed by the C standard that in case of
> overfllow the result of sum will be less then either
> operand?

There is no overflow of unsigned types with a rank of int
or above. [Lower ranks may promote to int in which case
overflow is possible.] But the quoted range check works by
virtue of modulo arithmetic necessary for unsigned int.

It's really quite simple to see. Consider a + b mod 2^n.
Now what non-negative number b would you need to add to a
to make the result larger than a (modulo 2^n)?

--
Peter

== 4 of 4 ==
Date: Wed, Mar 3 2010 9:28 pm
From: James Dow Allen

On Mar 4, 8:01 am, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
> Addition of unsigned numbers is well-defined by the C Standard for any
> input values; if the mathematical sum of a and b is greater than
> UINT_MAX then the result is the mathematical sum (a + b - (UINT_MAX +
> 1)), which can easily be shown to be less than b in all cases (and
> also less than a).

I've not worked on a one's-complement machine since before there
was a C language, but I wonder how they work here. Perhaps
UINT_MAX on such a machine is *two* less than a power-of-two,
rather than *one* less, which would impact the cute number-of-bits
extractor discussed here a year ago. :-(

> It isn't called "overflow" because ...

Yes. But it's certainly understandable why *some* might *call*
it overflow. Kudos to Christian who explained this,
rather than just snapping at a "non-compliant usage"
and leaving new c.l.c'ers confused. :-)

<just another useless factoid>
The IBM 370/145 did unsigned arithmetic ("logical arithmetic")
*much* faster than it did signed arithmetic! The data results
are *identical* and both operations set the condition code,
but the condition-code spec for the signed arithmetic
required a microcode detour that took longer than the addition
itself!

Since often one doesn't care about condition code, use of
the logical ops could have sped up some code. No idea if
any programmers were masochisto-perfectionistic enough to
worry about this....
</just another useless factoid>

James Dow Allen

==============================================================================
TOPIC: Call For Manuscripts: International Journal of Signal Processing (IJSP)
http://groups.google.com/group/comp.lang.c/t/5893df3c622249a3?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 5:18 pm
From: org ijsp

Call For Manuscripts
The International Journal of Signal Processing (IJSP) is currently
accepting original high-quality research manuscripts for publication.
The Journal welcomes the submission of manuscripts that meet the
scientific criteria of significance and academic excellence. All
research articles submitted for the journal will be peer-reviewed
within three weeks of submission. Following the peer-reviewed
acceptance, the accepted & formatted articles will normally be
published in the next available issue.

All submitted formatted full-text articles should report original,
previously unpublished research results, experimental or theoretical.
Articles submitted to the journal should meet these criteria and must
not be under consideration for publication elsewhere. These articles
should describe new and carefully confirmed findings, and experimental
procedures should be given in sufficient detail for others to verify
the work. The length of a full text article should be the minimum
required to describe and interpret the work clearly.

Papers are solicited from, but not limited to the following topics:

* Adaptive Filtering & Signal Processing
* Ad-Hoc and Sensor Networks
* Analog and Mixed Signal Processing
* Array Signal Processing
* Audio and Electroacoustics
* Audio/Speech Processing and Coding
* Bioimaging and Signal Processing
* Biometrics & Authentification
* Biosignal Processing & Understanding
* Communication and Broadband Networks
* Communication Signal processing
* Computer Vision & Virtual Reality
* Cryptography and Network Security
* Design and Implementation of Signal Processing Systems
* Digital Signal Processing
* DSP Implementations and Embedded Systems
* Emerging Technologies
* Hardware Implementation for Signal Processing
* Higher Order Spectral Analysis
* Image and Multidimensional Signal Processing
* Image Processing & Understanding
* Image/Video Processing and Coding
* Industry Technology
* Internet Signal Processing
* Machine Learning for Signal Processing
* Modulation and Channel Coding
* Multimedia & Human-computer Interaction
* Multimedia Communications
* Multimedia Signal Processing
* Natural Language Processing
* Next Generation Mobile Communications
* Nonlinear Signal Processing
* Optical Communications
* Parallel and Distributed Processing
* PDE for Image Processing
* Radar Signal Processing
* Rapid Prototyping and Tools for DSP Design
* RF and Wireless Communications
* Sensor Array and Multi-channel Processing
* Signal Processing and Communications Education
* Signal Processing for Communications
* Signal Processing for Security
* Signal Processing Theory and Methods
* Soft Computing and Machine learning for Signal Processing and
Communications
* Sonar Signal Processing and Localization
* SP for Bioinformatics
* SP for Biomedical & Cognitive Science
* SP for Internet and Wireless Communications
* SP for Sensor Networks
* Spectrum Estimation & Modeling
* Speech and Audio Coding
* Speech Processing
* Speech Synthesis & Recognition
* Spoken Language Processing
* Statistic Learning & Pattern Recognition
* Statistical Signal Processing
* TF Spectrum Analysis & Wavelet
* Time-Frequency/Time-Scale Analysis
* Video compression & Streaming
* Watermarking and Information Hiding
* Applications of Signal Processing (Biomedical, Bioinformatics,
Genomic, Seismic, Radar, Sonar, Remote Sensing, Positioning, Embedded
Systems, etc.)
* Signal Processing and Communications Education
* Web Engineering
* Wireless Communications
* Detection and Estimation
* Cooperative Communication
* Adaptive and Array Signal Processing
* MIMO and Space-Time Signal Processing
* Compressive Sensing & Applications
* Cognitive Radio
* Signal Processing for Communications
* Network Coding
* Machine Learning/AI for Signal Processing
* Network Information Theory
* Audio, Speech, Image & Video Signal Processing
* Sequences & Complexity
* Signal Processing Algorithms & Architectures
* Source and Channel Coding: Theory and Practice
* Underwater Communications and Signal Processing
* Ad-hoc and Sensor Networks
* Optical Communications and Networks
* Next Generation Networking, QoS & Security
* VLSI for Communication & Signal Processing
* Multihop and Mesh Networks
* RF Systems for Communications
* Vehicular Networks
* Systems, Standards and Implementations
* Biomedical Signal Processing
* Coding/Signal Processing in Biology
* Spoken Language Processing
* Biological Network & Data Analysis/Modelling

CALL FOR PAPERS
International Journal of Signal Processing (IJSP)
Website: https://sites.google.com/site/ijsporg/
IMPORTANT DATES:
Paper Submission Deadline: March 5, 2010
Notification of Acceptance: March 30, 2010
Publication Date: April 15, 2010
Manuscript submission to: ijsporg@gmail.com
All submitted papers will be judged based on their quality by the
technical committee and reviewers. Papers that describe research and
experimentation are encouraged. All paper submissions will be handled
electronically and detailed instructions on submission procedure are
available on IJSP web pages. Researchers and authors are invited to
participate in the peer-review process of IJSP papers if your research
interest matches with the themes of Call for Papers. For other
information, please contact IJSP Managing Editor.

==============================================================================
TOPIC: fixing compile warnings
http://groups.google.com/group/comp.lang.c/t/41e53e9bb82de6ec?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 3 2010 5:23 pm
From: deadpickle

Thanks for the reply.
Now I get a segfault. Is there a way to print the line causing the
segfault (aka traceback in fortran)?
I did try the old fashion way of locating it, with print statements.
It seems, by this way, it is coming from OSRSetFromUserInput(source,
sprj);. If so perhaps it is from those calls you mentioned. Here they
are from the ogr_srs_api.h file (http://www.gdal.org/ogr/
ogr__srs__api_8h.html):

OGRSpatialReferenceH CPL_STDCALL OSRNewSpatialReference (const char
*pszWKT)
OGRErr CPL_STDCALL OSRSetFromUserInput(OGRSpatialReferenceH hSRS,const
char *pszDef)

#include "ogr_api.h"
#include "ogr_srs_api.h"
#include "stdio.h"

int main()
{
//~ variable declaration
char *source, *target;
const char *sprj = "+proj=lcc +lat_1=33.000000 +lat_2=45.000000
+lat_0=39.000000 +lon_0=-96.000000 +x_0=0.0 +y_0=0.0 +datum=NAD83";
const char *tprj = "WGS84";
char c[100];
OGRSFDriverH driver;
OGRDataSourceH ds;
OGRCoordinateTransformationH ctrans;
OGRLayerH layer;
OGRFieldDefnH fieldDefn;
OGRGeometryH line;
OGRFeatureDefnH featureDefn;
OGRFeatureH feature;
FILE *file;

//~ working directory
chdir("C:\\Users\\deadpickle\\Desktop\\case study\\verify\\");

OGRRegisterAll();

//~ get driver and create ds
driver = OGRGetDriverByName("ESRI Shapefile");
ds = OGR_Dr_CreateDataSource(driver, "testc.shp", NULL);

if(ds == NULL) {
printf("Creation of output file failed.\n");
exit(1);
}

printf("HERE1\n");

//~ create spatrefs and trans
OSRNewSpatialReference(source);
OSRNewSpatialReference(target);

OSRSetFromUserInput(source, sprj);

printf("HERE2\n");

OSRSetFromUserInput(target, tprj);

printf("HERE3\n");

ctrans = OCTNewCoordinateTransformation(target, source);

//~ create the layer
layer = OGR_DS_CreateLayer(ds, "testc", source, wkbMultiLineString,
NULL);

//~ add an id field
fieldDefn = OGR_Fld_Create("id", OFTInteger);
OGR_L_CreateField(layer, fieldDefn, FALSE);

//~ create geometry
line = OGR_G_CreateGeometry(wkbMultiLineString);

//~ layer def and create feature
featureDefn = OGR_L_GetLayerDefn(layer);
feature = OGR_F_Create(featureDefn);

//~ open file
file = fopen("2006track.csv","r");

if(file==NULL) {
printf("Error: can't open file.\n");
/* fclose(file); DON'T PASS A NULL POINTER TO fclose !! */
return 1;
}
else {
printf("File opened successfully. Contents:\n\n");

while(fgets(c, 100, file)!=NULL) {
/* keep looping until NULL pointer... */
printf("String: %s", c);
/* print the file one line at a time */
}

printf("\n\nNow closing file...\n");
}

//~ close file
fclose(file);
}

On Mar 3, 2:12 pm, Keith Thompson <ks...@mib.org> wrote:
> deadpickle <deadpic...@gmail.com> writes:
> > when I try to compile my C program I get these warnings (at bottom).
> > Not sure how to fix them since I'm new to C.
>
> > #include "ogr_api.h"
> > #include "ogr_srs_api.h"
>
> > int main()
> > {
> >         //~ variable declaration
> >         const char *format = "ESRI Shapefile", *name = "testc.shp",
> > *source,
> > *target;
> >         const char *sprj = "+proj=lcc +lat_1=33.000000
> > +lat_2=45.000000
> > +lat_0=39.000000 +lon_0=-96.000000 +x_0=0.0 +y_0=0.0 +datum=NAD83";
> >         const char *tprj = "WGS84";
> >         OGRSFDriverH driver;
> >         OGRDataSourceH ds;
> >         OGRCoordinateTransformationH ctrans;
>
> >         //~ get driver and create ds
> >         driver = OGRGetDriverByName(format);
> >         ds = OGR_Dr_CreateDataSource(driver, "testc.shp", NULL);
>
> >         //~ create spatrefs and trans
> >         OSRNewSpatialReference(source);
> >         OSRNewSpatialReference(target);
> >         OSRSetFromUserInput(source, sprj);
> >         OSRSetFromUserInput(target, tprj);
> >         ctrans = OCTNewCoordinateTransformation(target, source);
>
> > }
>
> > dal_test_convert.c: In function ‘main’:
> > gdal_test_convert.c:22: warning: passing argument 1 of â
> > €˜OSRSetFromUserInput’ discards qualifiers from pointer target type
> > gdal_test_convert.c:23: warning: passing argument 1 of â
> > €˜OSRSetFromUserInput’ discards qualifiers from pointer target type
> > gdal_test_convert.c:24: warning: passing argument 1 of â
> > €˜OCTNewCoordinateTransformation’ discards qualifiers from pointer
> > target type
> > gdal_test_convert.c:24: warning: passing argument 2 of â
> > €˜OCTNewCoordinateTransformation’ discards qualifiers from pointer
> > target type
>
> gcc uses non-ASCII characters in its error messages unless you tell it
> not to.  I've found that setting the environment variable $LANG to "C"
> causes it to restrict itself to ASCII.  If you're using a Bourne-like
> shell (sh, ksh, bash, zsh), you can use:
>
>     LANG=C gcc ...
>
> For csh or tcsh:
>
>     env LANG=C gcc ...
>
> "env" works with Bourne-like shells too.
>
> In the above, it appears that gcc's output uses a UTF-8 encoding, but
> your article's encoding is windows-1252, so the quotation marks are
> not rendered properly (at least in my newsreader).  I'm seeing:
>
> dal_test_convert.c: In function â\200\230mainâ\200\231:
>
> Setting LANG=C before copy-and-pasting the error messages should avoid
> that problem.
>
> (Yes, this is very specific to gcc and to Unix-like systems, but it's
> something I see a lot in postings here.)
>
> Keeping your source lines below about 72 columns would also help.
> Several of your lines were wrapped by some news software somewhere.
> Adjacent string literals are concatenated, so you can split a long
> string literal like this:
>
>         const char *sprj = "+proj=lcc "
>                            "+lat_1=33.000000 "
>                            "+lat_2=45.000000 "
>                            "+lat_0=39.000000 "
>                            "+lon_0=-96.000000 "
>                            "+x_0=0.0 "
>                            "+y_0=0.0 "
>                            "+datum=NAD83";
>
> As for the problem you were actually asking about, it's difficult to
> tell without seeing the declarations for OSRSetFromUserInput() and
> OCTNewCoordinateTransformation().  But one obvious problem jumps out
> at me.  You declare (reformatted):
>         const char *format = "ESRI Shapefile",
>                    *name = "testc.shp",
>                    *source,
>                    *target;
> which means that source and target are uninitialized.  You don't
> assign values to them before passing them as arguments.  If
> OSRNewSpatialReference() is a macro, this might be ok.  If not, it's
> certainly a bug.
>
> --
> Keith Thompson (The_Other_Keith) ks...@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 4 ==
Date: Wed, Mar 3 2010 5:41 pm
From: Ian Collins

deadpickle wrote:

{please don't top-post]

> Thanks for the reply.
> Now I get a segfault. Is there a way to print the line causing the
> segfault (aka traceback in fortran)?

No, you should run your programme under a debugger and look at the stack
trace when it faults.

--
Ian Collins

== 3 of 4 ==
Date: Wed, Mar 3 2010 6:03 pm
From: Keith Thompson

deadpickle <deadpickle@gmail.com> writes:
> Thanks for the reply.

You're welcome.

The convention here is to avoid top-posting; instead, your response
should *follow* any quoted text, which should be trimmed to remove
anything not relevant to your response.

> Now I get a segfault. Is there a way to print the line causing the
> segfault (aka traceback in fortran)?
> I did try the old fashion way of locating it, with print statements.
> It seems, by this way, it is coming from OSRSetFromUserInput(source,
> sprj);. If so perhaps it is from those calls you mentioned. Here they
> are from the ogr_srs_api.h file (http://www.gdal.org/ogr/
> ogr__srs__api_8h.html):
>
> OGRSpatialReferenceH CPL_STDCALL OSRNewSpatialReference (const char
> *pszWKT)
> OGRErr CPL_STDCALL OSRSetFromUserInput(OGRSpatialReferenceH hSRS,const
> char *pszDef)

Ok.

[...]
> int main()
> {
> //~ variable declaration
> char *source, *target;
[...]
> //~ create spatrefs and trans
> OSRNewSpatialReference(source);
> OSRNewSpatialReference(target);
[...]

You're still passing the values of uninitialized variables to
OSRNewSpatialReference(). It's very likely that that's the cause
of the segfault. In any case, correcting that problem should be
the first thing you do.

I don't know what "CPL_STDCALL"; it's probably some
implementation-specific macro. Apart from that, it appears that
OSRNewSpatialReference requires a *meaningful* pointer value (not the
garbage you're giving it) and returns a result of type
OGRSpatialReferenceH (which you're quietly discarding).

--
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"

== 4 of 4 ==
Date: Wed, Mar 3 2010 11:24 pm
From: Nick <3-nospam@temporary-address.org.uk>

Ian Collins <ian-news@hotmail.com> writes:

> deadpickle wrote:
>
> {please don't top-post]
>
>> Thanks for the reply.
>> Now I get a segfault. Is there a way to print the line causing the
>> segfault (aka traceback in fortran)?
>
> No, you should run your programme under a debugger and look at the
> stack trace when it faults.

Although if you are still struggling to get to grips with the compiler
and want to put off learning the debugger for a bit (and sooner or later
you'll have to use it), you can find use the old stand-by of putting
temporary printing statements in key places in the code and finding out
how far it gets before it dies.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: problem 1.13 The C programming language
http://groups.google.com/group/comp.lang.c/t/e3b5a2688181479c?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 3 2010 5:33 pm
From: joag

This is my poor implementation of this program :D, I'd like to know where
I'm doing things wrong, I'm really new to programming (two month or so)
so please I need all the guidance possible in order to improve.

http://codepad.org/HyaIdtOl

Best Regards,
joag

== 2 of 2 ==
Date: Wed, Mar 3 2010 8:08 pm
From: Barry Schwarz

On Thu, 4 Mar 2010 01:33:34 +0000 (UTC), joag <jag1506@hotmail.com>
wrote:

>This is my poor implementation of this program :D, I'd like to know where
>I'm doing things wrong, I'm really new to programming (two month or so)
>so please I need all the guidance possible in order to improve.
>
>
> http://codepad.org/HyaIdtOl

For only 85 lines, it is better to include the code in your message.

Not that it is an error but why initialize an integer to 0.0 (line
21)?

Unless you are using C99, you need to put your declarations (line 21)
before your statements (line 20).

In your while loop, nword is indexed by the number of characters in
the current completed word (line 26). Do you ever expect to have a
word with 15000 characters in it (line 21)?

Let's assume the input was "abcd efg hijk$" where the $ represents end
of file. Your while loop will recognize abcd and increment nword[4]
(line 26) and nw (line 27), then recognize efg and increment nword[3]
and nw again. Unfortunately, it will exit (line 23) before it
finishes processing hijk.

At this time nw is 2 and two elements of nword have non-zero values.
Your first for loop (line 39) will process only the first three
entries of nword, all of which are zero. It never sees elements 3 and
4. You probably meant to use counter (which actually holds the max
word length +1 and therefore the last element +1 of nword which is
non-zero) and not nw as the loop limit. If you do use counter, change
the <= to <.

Why does this loop process nword[0] which gets incremented only if
there are two or more consecutive "spaces"? Why is the second printf
(line 41) which is not part of the loop indented as if it is?

Your second for loop (line 43) has the same limit problem.

Your fourth for loop (line 55) prints any non-zero value. This
guarantees that you build the histogram with low frequencies on top
and higher frequencies running down. If you test nword[j] against i
instead of 0, you can print the histogram in "normal" orientation.

Your first else if (line59) tests a condition which must be true. You
can replace it with a simple else.

--
Remove del for email

==============================================================================
TOPIC: Free Computer Hacking Tips
http://groups.google.com/group/comp.lang.c/t/bcf05b1319ec44a4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 7:07 pm
From: Bharathi

This website has been created to help you solve your computer
problems. We offer a wide range of Free computer tips, hints, and
tricks.

http://computertipzz.blogspot.com

==============================================================================
TOPIC: decoding a declaration
http://groups.google.com/group/comp.lang.c/t/259df4a3d0342511?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 11:34 pm
From: David Thompson

On Tue, 16 Feb 2010 21:28:25 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

> "t" <t@t.com> writes:
>
> > I am trying to decode a declaration "void *(*p[]) (void *a, int n)"
> >
> > Does it mean an array of pointers to a function taking
> > two parameters(one a void pointer, another an integer)
> > and returning a void pointer?
>
> Yup. That's it.
>
> > Or am I missing something? Which would be a good book
> > to understand how to decode such declarations?
>
> I don't know of a book, but you seem to have the hang of it. You read
> inside out from the name (respecting brackets), moving left in
> preference to moving right.
>
Other way; array and function to the right must be taken before
pointer (or C++ reference) to the left.
Overridden by en_GB brackets = en_US parentheses, to be clear.

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

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