Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

warning cleanup #2298

Closed
sergey-safarov opened this issue Apr 23, 2020 · 4 comments
Closed

warning cleanup #2298

sergey-safarov opened this issue Apr 23, 2020 · 4 comments

Comments

@sergey-safarov
Copy link
Member

ld_fld.c:273 implicit-function-declaration

CC (gcc) [M db2_ldap.so]	db2_ldap_mod.o
CC (gcc) [M db2_ldap.so]	ld_cfg.o
CC (gcc) [M db2_ldap.so]	ld_cmd.o
CC (gcc) [M db2_ldap.so]	ld_con.o
CC (gcc) [M db2_ldap.so]	ld_fld.o
ld_fld.c: In function 'ldap_gentime2db_datetime':
ld_fld.c:273:10: warning: implicit declaration of function 'timelocal' [-Wimplicit-function-declaration]
273 | *dst = timelocal(&time);
| ^~~~~~~~~
CC (gcc) [M db2_ldap.so]	ld_res.o
CC (gcc) [M db2_ldap.so]	ld_uri.o
make[3]: 'libsrdb2.so.1.0' is up to date.

redis_table.c:586 maybe-uninitialized

CC (gcc) [M db_redis.so]	db_redis_mod.o
CC (gcc) [M db_redis.so]	redis_connection.o
CC (gcc) [M db_redis.so]	redis_dbase.o
CC (gcc) [M db_redis.so]	redis_table.o
redis_table.c: In function 'db_redis_parse_keys':
redis_table.c:586:38: warning: 'table' may be used uninitialized in this function [-Wmaybe-uninitialized]
586 | table->types = type_target = type;
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
make[3]: 'libsrdb2.so.1.0' is up to date.
make[3]: 'libsrdb1.so.1.0' is up to date.
LD (gcc) [M db_redis.so]	db_redis.so

app_python strict-aliasing

CC (gcc) [M app_python.so]	app_python_mod.o
CC (gcc) [M app_python.so]	apy_kemi.o
In file included from /usr/include/python2.7/Python.h:83,
from apy_kemi.c:25:
apy_kemi.c: In function 'sr_kemi_apy_return_true':
/usr/include/python2.7/object.h:769:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
769 | ((PyObject*)(op))->ob_refcnt++)
| ~^~~~~~~~~~~~~~~~
apy_kemi.c:121:2: note: in expansion of macro 'Py_INCREF'
121 | Py_INCREF(Py_True);
| ^~~~~~~~~
apy_kemi.c: In function 'sr_kemi_apy_return_false':
/usr/include/python2.7/object.h:769:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
769 | ((PyObject*)(op))->ob_refcnt++)
| ~^~~~~~~~~~~~~~~~
apy_kemi.c:130:2: note: in expansion of macro 'Py_INCREF'
130 | Py_INCREF(Py_False);
| ^~~~~~~~~
CC (gcc) [M app_python.so]	apy_kemi_export.o
CC (gcc) [M app_python.so]	mod_Core.o

pdb.c:348 address-of-packed-member]

LD (gcc) [M p_usrloc.so]	p_usrloc.so
CC (gcc) [M path.so]	path.o
CC (gcc) [M path.so]	path_mod.o
LD (gcc) [M path.so]	path.so
CC (gcc) [M pdb.so]	pdb.o
pdb.c: In function 'pdb_query':
pdb.c:348:60: warning: taking address of packed member of 'struct pdb_msg' may result in an unaligned pointer value [-Waddress-of-packed-member]
348 | _id = (short int *)&(msg.bdy.payload[reqlen]); /* make gcc happy */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
LD (gcc) [M pdb.so]	pdb.so
CC (gcc) [M pdt.so]	pdt.o
CC (gcc) [M pdt.so]	pdtree.o
make[3]: 'libsrdb1.so.1.0' is up to date.
miconda added a commit that referenced this issue Apr 27, 2020
- timelocal() is nonstandard GNU extension, not recommended to be used
and mktime() should be equivalent:
  * https://linux.die.net/man/3/timegm
- GH #2298
miconda added a commit that referenced this issue Apr 27, 2020
- python2 is known for not confirming strict aliasing
- it is EoL and likely not going to be fixed
- GH #2298
miconda added a commit that referenced this issue Apr 27, 2020
@miconda
Copy link
Member

miconda commented Apr 27, 2020

I pushed patches for those warnings. The one of app_python is to disable the check, on the web people say python2 is known not to handle strict aliasing and being end-of-life, I guess is no chance to fix in the libs.

For pdb: @henningw, @lbalaceanu & @smititelu - you are likely the devs familiar with the code, can you check the commit 86ebb4e and see if it is an acceptable solution? The idea was to get the short int value from the two consecutive bytes in the char buffer, to avoid reading from an unaligned memory address when buflen is not round of 4 or 8. I see there is also conversion from network to host, so it is better you have a look, not to let this change go somehow unnoticed.

miconda added a commit that referenced this issue May 1, 2020
- timelocal() is nonstandard GNU extension, not recommended to be used
and mktime() should be equivalent:
  * https://linux.die.net/man/3/timegm
- GH #2298

(cherry picked from commit a0fb220)
miconda added a commit that referenced this issue May 1, 2020
miconda added a commit that referenced this issue May 1, 2020
- python2 is known for not confirming strict aliasing
- it is EoL and likely not going to be fixed
- GH #2298

(cherry picked from commit 3366bf4)
@miconda
Copy link
Member

miconda commented May 2, 2020

Closing, commits were also backported to 5.3.

@miconda miconda closed this as completed May 2, 2020
henningw pushed a commit that referenced this issue May 13, 2020
henningw pushed a commit that referenced this issue May 13, 2020
henningw pushed a commit that referenced this issue May 13, 2020
- python2 is known for not confirming strict aliasing
- it is EoL and likely not going to be fixed
- GH #2298

(cherry picked from commit 3366bf4)
henningw pushed a commit that referenced this issue May 13, 2020
@Earn330
Copy link

Earn330 commented Jun 3, 2020

Hi

i had to revert commit 86ebb4e because the return value wasn't correct anymore. It seems it just
returns the pointer position but not the content itself. After reverting everything worked fine again.

BR,
Bjoern

@miconda
Copy link
Member

miconda commented Jun 3, 2020

@Earn330 - create a new bug report and reference this issue, so it does not get forgotten and we investigate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants