your sed can also catch those of this form

there are plenty of other places where strncmp() is used in lib/ Why only thoses ?

i guess this one should be closed, no ?

• fix leak

in wayland too i think

also there too, then :
https://git.enlightenment.org/core/efl.git/tree/src/modules/ecore_evas/engines/cocoa/ecore_evas_cocoa.c#n521

i know but there are plenty of locations in efl source where there is such check, so i considered it's a convention in efl source

• remove debug
• add test on size and fix double free
• use eina_str_has_prefix() only once
• According to GlobalLock() documentation, GlobalUnlock() must be called on a successful GlobalLock() call
• fix logic
• free memory in clipboard notify event and fix clipboard clear event
• fix segfault when there is no text in clipboard

C code for me is good. I can't comment about eo part though

note that MAX_PATH exists on Windows and it's value is 256

• fix logic

• According to GlobalLock() documentation, GlobalUnlock() must be called on a successful GlobalLock() call

• use eina_str_has_prefix() only once

• add test on size and fix double free

• remove debug

@ali.alzyod try this :

it's unix, not windows. I also know unix prog... :-)

as discussed in IRC either :

evas_init() calls eet_init() line 145 of evas_main.c

i can inject a dll or exe in a process and call the functions in this dll/exe (a bit like PRELOAD). not sure if it can helps

on Windows, here is my script :

exactly. it was too odd. was it meson ? ninja ? some EAPI (or other similar macro) stuff ?

solved (though i still don't understand why it failed) : i unset PKG_CONFIG_PATH and it compiled flawlessly with my script. no problem with latest meson too

below are the shots of dependency walker for libevas-1.dll and libecore-1.dll

i used dependency walker which is a tool that parses the PE files (file format used for the DLL) and it reports something very strange : only 2 symbols are exported : fribidi_unicode_version and fribidi_version_info !?!?!? I don't understand, all the evas symbols should be here. There is no problem for other generated dll (ecore, eina, evil, etc...).

and include the .x file in the .h file

imho, making exactness working on Windows is a big task. What is done here is making it compile. Just looking at the diff above, I see "/tmp/etc..." which is not an existing dir on Windows

maybe i have found the problem

i think that there is one occurence here : doc/elementary_examples_cxx.dox: * @ref location_cxx_example_01

@ProhtMeyhet if there is no such warning on linux, then we can close the task

gcc for Windows, version 9.2.0. I guess that it does not detect that it is defined there :

btw, in code there are also TODO and XXX comments...

"Lastly, you've suggested to use cos rather than cosf before at D10467, jsuya agreed this patch as you can see his comment above. and I agree also."

is this accuracy really needed ?

to mimic Shakespeare:

so, what is the status of this diff ?

install_dir option

btw cosf returns a float, not a double

we can also increase _XOPEN_SOURCE to 700 (http://man7.org/linux/man-pages/man7/feature_test_macros.7.html)

otoh : https://lists.gnu.org/archive/html/autoconf/2010-08/msg00045.html it seems that we should not use __USE_UNIX98

@raster btw, eina_inline_posix_lock.x does:

@raster i've asked the user to export it to CPPFLAGS and issue vanished of course. I will provide a diff

@bu5hm4n i would say in eina as a user should not do extra work. Eina is using some features, it should enable them, imho.

it is garded. adding -D_POSIX_C_SOURCE=200809L in eina.pc (in CFlags) should be sufficient

strlcat does not exist on Windows

option b) is fine for me

Note that elementary makes ephoto unresponsive. Certainly a problem on Windows. I have plenty of this message:

we have plenty of dependencies, so if we can remove some, that would simplify everybody's life

shouldn't this be abandoned and rewritten for meson build system ?

should we add @private to the doc of the functions ?

plane reserved

no, EFL_BUILD is set in config.h, which is also used by binaries. see toplevel meson.build

maybe this should have been detected with a unit test too, no ?

i can't try the test, but i tried the code on a file, and it works with the change mentioned above