fixing compile warnings

[deadpickle]

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

[Malcolm McLean]

On Mar 3, 9:15 pm, deadpickle <deadpic...@gmail.com> wrote:
>
> 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.
>

The problem is that, when C was first developed, there was no const
keyword. So strings literal, which are constant, had to be non-const
for backwards compatibility.
This means that lots of programmers get lazy and omit the const, even
from functions which don't modify their string arguments. (There are
also some subtle problems with const which means that this isn't
always a case of pure laziness).
So a sort of solution is to discard the const qualifiers. However this
is perpetuating the problem in your own code.

[Keith Thompson]

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"

[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:

[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

[Keith Thompson]

deadpickle <deadp...@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).

[Nick]

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

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

[Ike Naar]

In article <b58c4b16-78cd-422d...@p3g2000pra.googlegroups.com>,

deadpickle <deadp...@gmail.com> wrote:
>Thanks for the reply.
>Now I get a segfault. Is there a way to print the line causing the
>segfault (aka traceback in fortran)?
>

> [snip]

>
>#include "ogr_api.h"
>#include "ogr_srs_api.h"
>#include "stdio.h"
>int main()
>{
> //~ variable declaration
> char *source, *target;

> [snip]
> OSRNewSpatialReference(target);

This is not correct; target is uninitialized and has an
indeterminate value; here your program goes off the rails.
Read the documentation for the OSRNewSpatialReference(target) function;
My guess is that the above statement should be

target = OSRNewSpatialReference(NULL);

[Keith Thompson]

Nick <3-no...@temporary-address.org.uk> writes:
> Ian Collins <ian-...@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.

If you do that, you need to make sure that each message actually
appears before the program crashes. Given:

printf("One\n");
/* do something innocuous */
printf("Two\n");
/* do something that segfaults */
printf("Three\n");

it's entirely possible that the line "One" will never appear, because
it was buffered rather than printed directly to your output device,
and the segfault zapped the buffer before it could be flushed.

You can either print your messages to stderr, or call fflush(stdout)
after each output operation, or call
setvbuf(stdout, NULL, _IONBF, 0);
to turn off buffering for stdout.

[Nick]

Keith Thompson <ks...@mib.org> writes:

Good point, thanks.